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 teleconf

The prelim minutes are attached.

Please send comments to the list.

Tom Rutt

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 – Feb 24, 2004


The meeting of the WSRM TC took place by teleconference 
Tuesday Feb 24 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 – 

3 Discussion of New Orleans Meeting and Conference papers

4 Discussions of Issues

5 Discussion of Editorial Comments

6 Discussion of Document Progression


Agenda approved

1         Roll Call


First Name

Last Name













Cyclone Commerce














TC Chair


























NEC Corporation






























Sun Microsystems


 Meeting is quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Marc will serve to record issue resolutions.

2.2      Approval of previous meeting minutes

Jeff  moved to accept the Feb 17 minutes. Jishnu  seconded.
No opposition, 2/17  minutes approved.


3         Discussion of New Orleans Meeting and Conference

Tom stated he told the OASIS staff that we wanted to meet all day Wednesday, and Thursday morning for our F2F.  This has been verified.



The panel discussion was not accepted, since only our TC members were on the panel.


We cannot determine who will be in the panel.


It is up to the TAB to decide who the participants are.  Jacques is lobbying to allow our original participants on the extended panel.


Jacques is continuing to lobby


Pete stated he sent an update to Jacques.


4         Discussion of Issues


4.1      Rel 108/115 Semantics of Polling and Fault Returns


New Proposal to Resolve Rel 108/115 thru unified Response Element


This proposes to make RM-fault reporting mechanism orthogonal to Soap Fault



The soap fault model will remain in place for faults associated with the soap

body of the request.


I propose that we not not map RM-fault to soap fault for any of our response

reply patterns.


Conceptually, it works to keep the rm fault model and the soap fault model

separate and distinct


If we take this principal, there is no Fundamental problem having a rm-response

indicate both acknowledgements and RM faults.


So given the above rational I propose the following detailed changes to resolve



Rewrite the Response Element section, 3.4 and schema to allow to have one

element returned per group being reported.


That element has a groupID attribute, and zero or more lists.

a) a list of sequence numbers to report messages in that group which have been

delivered. (for a singleton group ack this sequence number list is empty)

b) for each fault code which has been encountered for messages in that group, an

element which has the fault code and a list of sequence numbers which faulted

due to that code (for a singleton group ack this sequence number list is empty). 


This proposed response  mechanism does not include fault detail info, however

that could go into extensions to the reply elements if so warranted.


The detailed proposed changes to the schema and the response element text are

posted at:




Other changes are proposed as follows:


Remove the Fault element section, 3.5.


In Section 4, on Faults:


Lines 1243-1261 need to be replaced with the following:

4   Fault Processing

This section describes the protocol specific fault codes that are needed to

better describe the reason for ws reliability protocol processing failures .


We categorize the faults into 2 categories based on whether the fault was

generated because Reliable Messaging Headers are malformed or invalid or because

of the some runtime processing errors encountered by the RMP.


The former category is called Invalid Message Format fault set and the latter is

called Request Processing  fault set. They are explained in detail in the

following sections.



These protocol specific fault codes are returned by the receiving RMP within the

response  header element.


The WS reliability protocol does not directly map our rm faults  to the soap

fault model.


The soap fault model is used for reporting faults due to the request payload,

which fits the soap fault model better.


Thus an rm-fault could come in a soap fault message, but the reason for the soap

fault would be due to problems caused by the message payoad


Example case 1:

For wsdl request/response operation types, a soap fault can occur for a reliable

request which was delivered , but then encountered an application level fault

due to something wrong in the payload  (soap body of request which is not under

control of Sending RMP) or application processing space outside the realm of the

Receiving rmp.


That means a reliable messsage acknolwedgement can be delivered on a soap fault.


Example case 2:

For the response reply pattern, used with wsdl two way operation type, the

return message could conceivably carry an indication of an RM fault, which is

not itself carried on a soap fault.  The exact behaviour in such a case might be

an implementation matter.


A message with an RM fault indication MUST not be delivered by the Receiving RMP. 

If the message cannot be delivered due, say  an  request  fault, then there

would be no meaningful data for the responder to put  into the soap body for the

WSDL response.


In some implementations, the responding application may not be available to

participate in a decision to issue a Soap fault for this non delivered request.

With such an implementation, the RM fault indication could be carried on an http

response, which only includes the RM response header and an empty soap body.


Other implementations which are more aware of the wsdl operation definition,

might be able to also realize that a soap fault has occurred for that messageID. 

With such an implementation for the response reply pattern case, the RM reply

could be carried on a soap fault message associated with the wsdl operation



4.1 Fault Codes For Reliable Messaging Failures


The following fault codes may be caried in an RM response element associated

with a meesage ID.


Excerpt of new text:

2.x Response element

A receiver MUST include the Response element to indicate Acknowledgments for reliable messages and indications of reliable message Faults . This element includes the following attributes:

o        SOAP mustUnderstand attribute with a value of “1”

o        a ReplyPattern attribute, which defaults to the value “Response”

At least on of the following child elements MUST be present in the Response element:

o        NonSequenceReply element, which can have zero or more occurances

o        SequenceReplies element, which can have zero or more occurances

When the response is using the callback reply pattern, if the reply and the new request share a common destination URI, a Response element can coexist with a Request element, enabling the combination of an Acknowledgment message with the business response to the original message. This coexistence also enables a receiver sending another independent message to the sender with an Acknowledgment message (e.g., to reduce network traffic).

Table 14 Response Element


0 or 1






Child elements





xample 7 shows an example of the Response element.


Example 9 Response Element






   <NonSequenceReply groupId="mid://20040202.103832@oasis-open.org/">

   <NonSequenceReply groupId="mid://20040202.103811@oasis-open.org/" fault="wsrm:PermanantProcessingFaulure"/>

   <SequenceReplies groupId="mid://20040202.103807@oasis-open.org/">

<RangeReply from="1" to="4"/>

<RangeReply from="5" to="5" fault="wsrm:InvalidMessageHeader"/>

<RangeReply from="6" to="42"/>




  (1) replyPattern attribute

If the response Element is being returned as a result of a poll request, this attribute must have the value “Poll”.

If the response is being returned as a reliable message callback, to return replies sent using the Callback reply pattern, this attribute must have the value “Callback”.

If the response is being returned using the Response reply pattern, this attribute indicate the “Response” value, which is the default for this attribute. In the case of a response returned using the Respose reply pattern, the following restrictions apply:

·         If the group does not use sequence numbers, the first element of the response must be a NonSequenceReply element containing the groupID which is the message ID for the reliable messaging Request.

·         If the group uses sequence numbering, the first element of the response must be a SequenceReplies element, with its groupID equal to that of the request, and with its first Range element having its from and to attributes both equal to the sequence number in the request.


Sunil pointed out we are missing the soap client fault, server fault categorization.


Someone could send fault detail strings as an extension.


Attributes lower case.


Propose to remove the default on


Change range reply to replyRange.



Tom Rutt wrote:


> Lines 1019 thru 1024 currently state the following:


> “

> - *Response *: An Acknowledgment message (or Fault message) MUST be

> sent back

> directly in the response to the Reliable Message. This pattern is not

> applicable for one-way application level MEP. The acknowledgment

> message that can be sent back in the response is for the message in the

> request only. Acknowledgment message for the former request

> MUST NOT be sent back.

> “


> To allow the receiving RMP to return acks or falts for former

> requests, the last two sentences are too strong:


Discussions have led to a concensus that the spec should be silent on

sending extra information in the response for the response reply pattern.


The proposal to resolve rel 108 and rel 115 includes restrictions on a

response element pertaining to  response reply pattern.  These are

the more approprate way to state the requirment, without disallowing

extensions to provide more information.


Delete  the last two sentences:


The acknowledgment message that can be sent back in the response is for

the message in the

request only. Acknowledgment message for the former request MUST NOT be

sent back.


Sunil moved to accept the proposal with the editorials from Sunil.  Jeff seconded.


No opposition, close rel 108/115.

4.2      Rel 113 Message Delivery processing after Fault.


Detailed proposal to Resolve Issue Rel 113



Lines 526 thru 532 currently state:


If the RMP sending a Reliable Message does not receive an Acknowledgment

for a sent message that has not yet expired, it MUST resend the same

message with same Message Identifier to the receiver RMP until the

sender gets an Acknowledgment message from the receiver, or until the

number of resend attempts specified by the RetryMaxTimes agreement item

is exhausted, whichever occurs first. The time interval between two

retries is specified by the RetryTimeInterval agreement item. If the

sender RMP fails to send the message (i.e., no Acknowledgment is

received), the sender RMP MUST notify a delivery error.


This does not talk about fault conditions.


Proposed Change:


Change “Acknowledgement” to “Acknolwedgement or Fault” in the first

sentence of the text quoted above.


Add the following paragraphs immediately after the exsting line 532:


The sending RMP MUST NOT send retries with a message ID, for which it

received an rm-response with one of the following fault types:


    *      an invalid message format fault code (table 18)

    *      an unsupported feature fault code

    *      a permanent processing faulure fault code


The RMP MUST NOT return an RM fault for a delivered messageID.


The RMP MUST NOT deliver a message which encounters an RM fault.


Add the following paragraph immediately after exsiting line 660:

The receiving RMP MUST NOT update its Group Termination Criterea using

parameter values from a rm-request which encounters an RM fault.


Sunil suggested the fist list be any fault except the messaging processing fault.


Chris suggested to exclude the transient fault in the group termination criteria.


Jacques re-itereated that the retry is exactly the same message with exactly the same header values.


Tom suggested to Change the last requirement to

The receiving RMP MUST update its Group Termination Criterea using

parameter values from a rm-request, even if that request encounters an RM fault.


Jacques moved to accept amended, Jishnu seconded.


No opposition, rel 113 resolved.


4.3      New issue on elimination of Message Header on Request


Proposal to resolve New issue on need for MessageHeader in Poll Request:


If a poll request is not piggybacked on a reliable message request., it

does not need a message header. There is no meaning to expiry time for

the poll request, and there is no need for a message id for the poll

request itself.


It would simplify the protocol if the poll request message, which is not

itself piggybacked on a new reliable message request, does not include

the request header.


In addition, this change would allow the Request header to be merged

with the MessageHeader, so further simplify the protocol processing.


Detailed Changes Required:


Lines 873 and 874 have the following Sentence:


A RMP MUST include a MessageHeader element in a Reliable Message, a


message, an Acknowledgment message, or a Fault message.


Change this to the following:


A sending RMP must include a MessageHeader element in a Reliable message.


lines 900 and 901 state the following:


The RMP MUST include the MessageId element for Reliable Message,


message, Fault message and PollRequest message.


This needs to be changed to the following:


The sending RMP must include the MessageID element for a reliable message.


Merge the existing section 3.2 into Section 3.1. add the three child

elementsack requested”, “DupicateElimination”: and “MessageOrder” at

the end of the MessageHeader.


Rename the new merged section 3.1 to be “Request Element”


Change all occurences of “Message Header” to “Request Element in the

entire document.


Remove the “InvalidMessageHeader” fault from the tables in section 3.1

before line 954


Merge the explanatory text after line 1266 in table 18 from the

InvalidMessageHeader fault into the InvalidRequest fault: as follows:


InvalidRequest -

This fault is sent when the Request element is wrong or invalid.

Examples are:

1.When any of the mandatory elements such as MessageId, ExpiryTime,

ReplyPattern are missing

2.SOAP:mustUnderstand attribute is missing

3.When AckRequested, DuplicateElimination or MessageOrder elements

appear twice

4.SOAP:mustUnderstand attribute is missing


.Change the message format pictures in Section 3 to take MessageHeader

out of the poll response message.


Change the message format pictures in Section 3 to merge MessageHeader

and Request element into a new Request element.


Lines 1099 thru 1101 , in the existing section 3.3 state the following:


A sender MUST include the PollRequest element only in the PollRequest

message as shown in

the Figure6. The PollRequest message contains two direct child elements

for SOAP Header

element. The one is MessageHeader element, and the other is the

PollRequest element.


change this to the following:


A sender MUST include the PollRequest element only in the PollRequest

message as shown in

the Figure6. The PollRequest message contains the PollRequest element.


Nobody has a concern about the merger.


Jacques stated the the reason we had a separate header was that the elements in the header could be replaced by other web service standards.  However, the request header now only has only ws reliability specific elements.


Jacques did not like the word request, because it is overloaded.  This could be confused with a wsdl response sent as an rm.


John Fuller stated we should change it from the name header.  It is not common.


Sunil: I like RM Request as the title. Also RM response.


Sunil Proposal:

               RMRequest,  RMResponse, RMPollRequest:


Sunil can propose name changes later.


Ok with using Request for merged element.


Jeff moved, Jishnu seconded to accept proposal.


No opposition, motion passes.

4.4      Issue 49 WSDL Annotation


Anish stated this proposal is to resolve Rel 49 on how to annotate.  He gave an overview of the proposal, which he characterized as a backport of the work in wsdl 2.0.

The following email was discussed:

Jacques Durand wrote:


> Anish:


> that looks clean, not overloaded, and I believe can be introduced

> as naturally as any previous annotation mechanism.


> See inline comments tagged <JD> in attached doc.


> - I think the proposal needs be more explicit on how

> to express “required-to-use” features vs. “”supported” features.

> I gave it a try in my comments.



Thanks for the comments.

The idea of the compositors is that, the compositor semantics specify whether something is required or just supported. Perhaps the examples need an explanation which might make things clearer.

Of the four compositors:

all” : Every element (feature/property/extensibility-element) that is composed is ‘required’.

choice” : Exactly one element is required but all are supported

“one-or-more” : at least one is required but all are supported

“zero-or-more” : none is required but all are supported.


Jacques, we need to make this clear in the spec.


Comments and example in your <JD> annotation under section VI.A :


>Let me know if I got these right:

>- I guess we can use a "zero-or-more" composer to mean that the


>features are all supported but optional for client.

>- to say that a feature below is NOT supported, would require a "false"


>under an "all" composer (e.g. for message-ordering).

>- to say that you must use either poll or callback but NOT response


>would require:

><compositor "all">

><compositor "one-or-more">








You got it exactly right!



> - these annotations map clearly to the notions of RM Agreement and RM Capability,

> of which they are a concrete representation.

> I think it is the proof that WS-Reliability is open to externally defined

> ways to express WS policies, and proposes the right abstract notions to help this.


> Jacques





The first document is generic.


The second is specific to WS reliability.  Features and properties are defined for wsdl services.


The client side deployment descriptors are the configuration parameters, which do not go in the wsdl document.


Tom asked about the conformance.

The following is in the proposal:



Implementations of WS-Reliability are expected, though not required, to

understand the WSDL extensibility points defined in this proposal.


Understanding of these extensibility points promotes interoperability. When a

WSDL document contains these extensibility points, it is through these

extensibility points that a service advertises its supported and required

features. Therefore it is RECOMMENDED that implementations recognize,

understand and support these extensibility points.


It is also possible for services to advertise features through other channels

(such as UDDI) in addition to these extensibility point. Mandating that every

conformant implementation recognize, understand and support these

extensibility points is considered to be too high a bar for conformant

implementations. Therefore, it is not required (though recommended) that every

conformant implementation support these extensibility point.


Tom: who is responsible to do this.  Could it be a human programmer hand coding from the values in the extension.


Anish: it could be the wsdl processor to do it, 


RMP is separate from wsdl.


Jacques: I agree that this notation would not have to have meaning for the RMP.  It is a notation to allow a web service to indicate it capabilities.


Tom: every other feature of our spec is optional for implementation.


Anish:  some wsdl processing will be able to automate the tool chain to configure the rm properties from the service description.


Jacques: It is a good annotation syntax.  The compositors does the job very well.  There are good ways to use them, and bad ways.


If we are explicit on their use, it will help.  The all features, could each have several choices.  That means the user could have complicated nestings of compositors.


This can be mapped to rm agreement and rm capability.


The syntax is not heavy.


In general:


Marc G:  I have concerns.  This proposal just came in.  I am concerned about backporting generic features.  I have to have discussions before I can agree to support this.


Is features and properties stable in wsdl 2.0.


Anish: I believe they are there to stay.  There is a face to face next week, this is on the agenda.


Tom: we would be agreeing to our specific way to do it for this version.  We would have to put it all in our document.


Chris: I have some slight reservations, this is a wsdl 2.0 draft.  2.0 might move.  WSs is the fist to need this.  Are they using it.


Tom: All of this would have to be in our spec.  We would be standardizing it.


Anish: Wsdl 2 probably will change.  However, this is based on wsdl 1.1, and is closely matched to the wsdl 2 proposal.  It will not be a big deal to do both ways in the future.


Briing to email list.

4.5      Soap fault for missing reliability features in request


We need a Generic SOAP fault for WS-reliabililty


What fault, if any, can a service send back to a client, when the

service requires that all clients communicating with it MUST use

WS-reliability (or specific feature(s) of reliability), but the client

sends a message that does not contain the (right) WS-reliability headers?


Interop requires not only defining what header to use and when but also

what faults to generate when the right headers/specs are not used. E.g,

consider a service that requires the use of callback, but a client sends

a message which does not specify the reply-to address.


 It would be worthwhile to define a SOAP fault for such purposes.


Jacques, I am not sure if that is a problem  A sender might send a non reliable message, the receiving rmp has no way to know about the contract.  The contract is driven from the sender side.  


Log as new issue.


4.6      Clarification Issue on Service enforcement of agreement


I just realized a new issue for clarification:



What is the expected service behavior when the client does not respect

the agreemen (i.e, contract) specified for a web service (conveyed

through whatever means)?


In this case, is it required that the service send a fault OR is it up

to the service implementation to decide. This has conformance

implications for the service.



   a service that requires the use of callback (as specified in the

service contract) receives a message that uses another mechanism for

reply,    can the service still process the message OR it it required to




Log as new issue


4.7      Sunil new Issue on Callback for Poll Request


  • New Issue
    From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on
    24 Feb 2004 00:50:10 -0000


Sunil: sent a proposal for a reply to on the poll request.


Tom: you seem to be adding a new requirement.  An asynch poll was not in the requirements.


Sunil: our requirement never said the response has to be synchronous.


Tom:in the definitioan for poll, s the response is on the underlying response.


Sunil, there is a need for a poll when only have oneway information. flow


Tom: take this to the list for discussion. Please express your opinion on the list.


Log as new issue


5         Discussion of Editorial Comments.

Editorial Comments for Discussion


No problems with Jacques reshuffle.


Go ahead with it for the next version.



6         Timing of WS-Reliability progression


Iwasa will have another editor’s draft by the end of tomorrow.


Get in by Monday morning.


Sunil will give a new schema with the amendments form these minutes..


Tom stated it is important to have a public review underway before the next WS-I plenary, on March 16th.


Timeline proposed at F2F meeting.

  1. Feb 10   Tuesday call, final editing instructions agreed.
  2. Feg 12 – Document posted for TC internal review.
  3. Feb 24 – TC review comments resolved, editing instructions produced.
  4. Feb 25  Frozen document completed, TC review begins.


These dates will likely be delayed by one week.

  1. March 2 – CD 1 ballot closes
  2. March 5 – 30 day Review initiated
  3. April 5 – 30 Day public Review ends
  4. April 15, submit to oasis staff for member vote
  5. May 01– Membership two week review
  6. May 15  – start member two week vote
  7. May 30 - member vote concludes.  Earliest Oasis Standard.


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