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/27

prelim minutes are attached.

please send corrections to the list

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

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Prelim Minutes WSRM TC Conference Call – Jan 27, 2004


The meeting of the WSRM TC took place by teleconference 
Tuesday Jan 27 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes - http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5166/Minutes-Jan04f2f-b.htm

3 Discussion of New Orleans Meeting and Conference papers

4 Discussion of Action Items - http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5090/Action%20Item%20List%20from%20Jan%20Face%20To%20Face%20Meeting.htm

5 Discussions of Issues


Agenda approved

1         Roll Call


First Name

Last Name








Booz Allen Hamilton





Cyclone Commerce














TC Chair









































Sun Microsystems





Sun Microsystems





University of Hong Kong


Meeting was quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


The minutes will serve for issue resolutions.

2.2      Approval of previous meeting minutes


Jeff Turpin moved to accept the Jan f2f  minutes. Tom Rutt  seconded.
No opposition, f2f  minutes approved.


3         Discussion of New Orleans Meeting and Conference

Tom Rutt received the following mail from Oasis Staff:

Hello Chairs,


This is the preliminary schedule that we have for TC meetings in New

Orleans. As you can imagine, we need to guarantee a quantity of sleeping

rooms in order to get the meeting room space at no charge, so it's important

that I get a final commitment. Please confirm the number of TC members that

have booked their rooms and please confirm the meeting times for your TC. I

can not confirm meeting rooms until reservations are made. Also, please let

me know if you need 1/2 day instead of full day, plan to meet from

8:00am-12:00pm or 1:00-5:00pm. Thank you for your prompt reply.





Small Room One


Wednesday - OASIS Board

Thursday - OASIS Board



Small Room Two


Wednesday - OASIS WS Reliable Messaging TC

Thursday - OASIS WS Reliable Messaging TC



Large Room Three


Wednesday - OASIS Legal XML Member Section Electronic Court Filing Technical


Thursday - OASIS Legal XML Member Section Electronic Court Filing Technical




Large Room Four


Wednesday - OASIS ebXML Registry TC

Thursday -  WS-CAF TC



Small Room Five


Wednesday - OASIS XDI TC

Thursday - OASIS Emergency Management TC


Small Room Six


Wednesday - OASIS ebXML CPPA

Thursday - OASIS CAM TC


Small Room Seven


Wednesday - OASIS ebXML Messaging TC

Thursday - OASIS ebXML Messaging TC


ebXML messaging TC  is slated to meet both days. Ian Jones is chair.


Their teleconf is tomorrow.  There is overlap between their group and ours.


Decide at next meeting if we will go for two ˝ days..


Both currently full day wed and thur.


Two half day meetings might be the best.


Decide at next meeting.


Sunil: we need to finalize our plans for the panels  .


Jacques: Two panels Implementation issues, and one on integration with other specs.


Tom: will Put on agenda for next teleconference.


Everyone Send email to me soon if you are planning to attend the meeting.  Make reservations now to get the oasis block.


Send your plans for papers to the email list before the next meeting.


Jacques will host the next meeting.


Jacques: for Presentation submissions, everyone willing to do so should do it on their own.  They are private initiatives.  However, to avoid competing proposals, within our group we could notify others of our intent to submit.


Pete: I like Jacques Idea. 


Jacques: We would publicize on the list our ideas for a submission.


Put list of talks planned on next meeting agenda.

4         Discussion of Action Item Status from Jan F2F meeting

Action Item List Status - from Jan Face To Face Meeting



1.      ACTION: Need to ensure faults in general being Cleaned up  Sunil will try to get a proposal to clean up fault text before the end of the F2f.. - DONE

2.      Action: Iwasa to apply changes for reo 44, then we will change status after done – done 3.1.1.

3.      Action: Iwasa is to produce a change barred version of all the changes made from the 1-06 document.  Use compare documents under Edit to do it. - done

4.      ACTION: Sunil took action to come up with additions to the model text for section 2.1 by Friday. – Done Suni updated section 2 for polling

5.      ACTION: Jacques will make a proposal to fix these group semantic concerns. Done, sent proposed updated wording to Iwasa, which he has consolidated in last spec draft. See section 2.2 ("Groups of messages and message identity").


6.      ACTION: Iwasa needs to remove the sentence on the description of invalidExipiryTime stating it is sent when the message expires. – done at 4

7.      ACTION: Iwasa has to factor in the new syntax for the message Id schema in section 3.3.  The sections need to be rearranged since some items have been changed from elements to attributes., and some of the names have changed - done

8.      ACTION: Sunil will provide text to include in the specification for what is not covered by existing protocol for request/response support. – done, see AI 9

9.      ACTION: Sunil will put a statement in a note regarding reply pattern for one-way wsdl operations, to add to the operation/replypattern table. Done – text needs to be incorporated by Iwasa.

  Section 2.9


  This specification supports Reliable Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response operation types only. While a Request-reponse operation can use any of the three RM-Reply patterns to receive acknowledgments or faults, an One-way operation can only use either Callback or Poll RM-Reply pattern. See the table below for a complete support matrix:


                        <insert chart 1>


  Insert another foot note for Supported items for R-R operation under Callback and Poll patterns.


  For that footnote, description should be: While the specification doesn’t prohibit using Callback or Poll RM-Reply patterns to receive acknowledgments or  faults for a Request-response operation, it is encouraged to use Response RM-Reply pattern for such operations as the acknowledgment or the fault can be sent on the same response itself thus saving extra round trips.


1.      ACTION: Iwasa will change MAY OPTIONAL for parameters to use cardinality instead, for the entire document. – open

2.      ACTION: Sunil will provide a complete spec of the wsdl extension feature before we decided on the resolution. Action Item closed, will discuss Issue later.

Done. Sent an email on Jan 20th. http://www.oasis-open.org/archives/wsrm/200401/msg00079.html

   -One change there after. Add the usage attribute with 2 different values (optional and required) on all the 3 elements.

3.      ACTION; Sunil will incorporate the processing faults into his fault proposal for review on Friday morning. – done see AI 14


4.      ACTION: Iwasa to change, in the first sentence of definition of guranteed delivery to: “A message submitted to the sending rmp with guaranteed delivery requested, will either be delivered by the receiving rmp, or the sending rmp will notify the submitter of failure. “ – done section 2.3

5.      ACTION: Sunil will provide a new section 4, - done

Done. Sent an email on Jan 20th.  http://www.oasis-open.org/archives/wsrm/200401/msg00078.html


6.      Action: Iwasa to add sentence: This element has cardinality zero or 1 in the rm-request message. – done in 3.3

7.      ACTION: Iwasa to add explanation for the table rows in Section 3: e.g., for cardinality: “cardinality is a constraint on the number of instances of an item type which may be present in an enclosing item.” - open

8.      Action: Iwasa will finish updating section 3 to fully reflect the syntax changes for message references. - done

9.      Action: Sunil will update the schema. – done and put in latest spec

Uploaded the schema (http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5057/ws-reliability-2004-01-16a.xsd)

     - Fixed a typo there after. Element name under MessageId should have been SequenceNum and not SequenceNumbe

10.  ACTION :Sunil will come up with text to resolve this issue on clarification of Poll semantics.. – done, Iwasa will add the text to the document.

I’d like to propose that we add a new sub-section under Section 2 to explain in detail the Poll semantics and usage.


   Section 2.X Poll Reply Pattern Semantics and Usage


   Guaranteed Delivery will be most commonly used for a one-way message as the Sender know the status of the message delivery otherwise.


   So the most common use case would be to use AckRequested with Callback RM-Reply pattern so that the Sender can receive the acknowledgement or a fault on a listener at its end. However this pattern doesn’t help when the Sender is within a firewall, as one cannot receive requests without opening a firewall, thus causing security lapses.


An alternate solution would be for the Sender to ask the Receiver for the receiving status of the message it has sent earlier on a different channel. Such a pattern is called the poll RM-Reply pattern. The Sender sends a Poll request for a message it would like to inquire and the Receiver sends a Poll response with the acknowledgement.  The Sender can also batch multiple Poll requests for an efficient use. Receiver in such case will send acknowledgements for those messages it has received. If a Poll request is partially or completely  invalid or wrong, then the Receiver sends either a InvalidPollRequest  or InvalidMessageId Fault back.


Also, a RM Poll response MUST NOT be piggybacked on a different RM Poll request.


11.  ACTION: Iwasa will add sub-section to section 3 for Fault element. – Sunil and Jacques will help Iwasa  Still open

12.  ACTION: Sunil will update to have the soap 1.2 mapping of ws-reliability will not use the rm:fault element, but instead will use the soap 1.2 Subcode element. Done

Done. I’ve mentioned in the Section 4.0 of my write-up.  Iwasa need to add this in Section 3 when describing the Fault element.

13.  ACTION: Iwasa will put soap 1.2 statement in the new section in 3 on rm:fault element. – still open

14.  ACTION: Sunil will incorporate amended fault proposal into the Schema and into the new text for section 4. Done see AI 14


15.  ACTION: Iwasa will update section 3 to accommodate the new fault proposal – Same as Action Item 20. – Close as duplicate

16.  ACTION: Sunil add text that a response to a poll may not coexist with a rm:request header.  Done see AI 19


17.  ACTION: Iwasa make the changes requested by Jacques for section 2 lead in. - done


18.  ACTION: Jacques will add clarification of sender/receiver synch of termination  criteria for his homework on clarifying group termination. Done, provided to Iwasa as an updated draft, where the Group termination section has been significantly reworded.

19.  ACTION: Iwasa will start working on new examples. – still open.  Sunil will send the roughed out schema examples.  Tom Will help send the examples to Iwasa.  Still Open Sunil will send out new schema at the end of this meeting.

20.  Action: Editors will produce up to date issues list by the next meeting. done

The 16th posting is the latest, but it is not a complete reflection of the meeting..


The action items need to be reflected.


The issues editors Will provide another issues list as soon as possible..

0         Discussion of Issues

0.1      Issue 49 WSDL Annotation

Normative but optional for use.



A few comments, which I don't see critical, but even if we keep the annotation

as you propose, we need to explicitly state which of the following semantics it has:


- It should be possible to express that only input messages are concerned by the RM features

even when attaching a service config annotation at service / port / op level, (i.e. without having to

"override" at message level, in order to exclude the output message.)

E.g. scope="input", (future versions will handle: scope="output", scope="input-ouput")


- The annotation you propose is not always about capability: in some cases the RM features *must* be used

by the client. In other words, the annotation may have different meaning

for each side. Consider the following cases, each gives the annotation a different meaning:


1. server capability (this is your service config I think): WS supports this RM feature if client asks for using it.

Attribute: clientuse="possible".


2. client requirement: client must use the feature, because the WS implementation assumes it does

for a proper WS behavior (e.g. ordering required, when using repeatedly a monitoring operation)

Attribute:  clientuse="required".


3. server requirement: E.g. WS1 is a deployed pay-per-use WS, which will respond to users via requests

issued to users. The user then has to implement a "response" WSDL, describing a service WS2 that

supports these requests. So we may want to specify in the WSDL 2 that the WS implementation or

deployment  MUST support the RM feature, because the client (here the deployed WS1) will use it.

Attribute: serveruse="required" (or clientuse="possible"?)


Beyond this, it becomes user-specific (e.g. according to an SLA) and would require more advanced

policies or agreements attached to user ID.




    -----Original Message-----

    From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]

    Sent: Tuesday, January 20, 2004 2:57 PM

    To: wsrm@lists.oasis-open.org

    Subject: Re: [wsrm] [REL-49]proposal for REL-49



     Here is my AI from the last F2F  to simply the proposal for REL-49.


     Salient points are:


        * A non-normative proposal for annotating Service WSDL with WSRM capabilities

        * Based on WSDL  extensibility element concept.

        * Defines only one extensible schema element (ServiceConfig)

        * This element could be used at any of the following WSDL levels:

              o message/input/output/operation/binding/bindingOperation/port/service

        * This service element could be used inside any vendor specific policy elements or directly.


     Example of a <ServiceConfig> usage inside the operation 'foorBar'.


    <portType name="fooPortType">

      <operation name="fooBar">

        <wsrm:ServiceConfig xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" >



                <!-- List the reply patterns supported by this service.  -->








            <wsrm-message-ordering />


         <input message="fooMessageIn" />

         <input message="fooMessageOut>




     Schema for such an element would be:

     <xsd:element name="ServiceConfig" type="wsrm:ServiceConfigType" />

     <!-- ServiceConfig WSDL Extensible Element Type -->

     <xsd:complexType name="ServiceConfigType">


       <xsd:extension base="wsrm:RmBaseType">


         <xsd:element name="wsrm-guaranteed-delivery"  type="wsrm:wsrm-guaranteed-delivery-type" minOccurs="0"/>

         <xsd:element name="wsrm-duplicate-elimination" type="wsrm:EmptyType" minOccurs="0"/>

         <xsd:element name="wsrm-message-order" type="wsrm:EmptyType" minOccurs="0"/>





     <xsd:complexType name="wsrm-guaranteed-delivery-type">


       <xsd:extension base="wsrm:EmptyType">


         <xsd:element name="reply-patterns" type="wsrm:reply-patterns-type"  />





     <xsd:complexType name="reply-patterns-type">


       <xsd:extension base="wsrm:EmptyType">

        <xsd:attribute name="callback" type="xsd:boolean" use="optional"/>

        <xsd:attribute name="poll" type="xsd:boolean" use="optional"/>

        <xsd:attribute name="response"  type="xsd:boolean" use="optional"/>









Jacques, if this was normative, some people may think that it stable and available for use.  I am not sure making it normative.  We need to ensure it is stable before making it normative.  If we keep it non-normative, people know they are on their own, without guarantee.


Tom: would an informative annex be treated as an example only.


Jacques: it could be seen as an informative mapping of capabilities to a wsdl extension.


Sunil: my preference would be to make it non-normative. 


Where will the schema namespace come from.


Jacques: This is brand new sub branch of reliability, expressing capabilities in wsdl.  It warrants further study.  Making it normative, implies it is quite stable.


Email from Jacques for text to go at end of section on RM Agreement:

RM Capabilities


The ability of an RMP to support items of the RM Agreement can be represented by an RM Capability. The RM Capability of an RMP is a subset of the previous RM Agreement items, with a set of supported values for each of them. Example:


        GuaranteedDelivery (enabled, disabled)

        AtMostOnceDelivery (enabled, disabled)

        GuaranteedOrdering (disabled)

        ReplyPattern ("response", "poll")


The RM Capability above tells that GuaranteedDelivery and AtMostOnceDelivery RM Agreement items are supported, but  GuaranteedOrdering is not ("disabled" only), and all reply patterns except "callback" are supported. The RM Capability of a Web service can be represented in its definition document (WSDL) (see Appendix ...).


Sunil: I could agree with an informative annex without the namespace for the elements.


Jacques: my text is not normative, for it does not prescript any specific way to implement an rmp.


Assign action item to Jacques and Sunil to draft final proposal for text in section 1.9 in latest draft, or 1.10.   Sunil will send out appendix and Jacques will propose text for section 1.


1         Editorial Review of Draft

Iwasa sent out a draft.



Editorial comments on spec should be sent to the list.


Adjourn .






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