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: Preliminary Minutes of WSRM TC 6-17-03

The prelim minutes are attached.

Please provide comments before Friday Morning.  I will then post the 
final minutes.

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


Preliminary Minutes to WSRM TC Conference Call – June 17, 2003


5:30 to 7:30 PM Eastern Daylight Time


1         Roll Call


First Name

Last Name
















































































TC Chair







France Telecom



12 out of 31 Voting members

14 total attendees


TC meeting not quorate.  Minutes will record concensus as pending resolutions (not final until future vote of quorate TC).


2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt volunteered.

2.2      Approval of Face to Face minutes


Face to Face Meeting Minutes:



Not quorate, leave for future meeting. 

3         Approval of Issue Resolutions from F2F meeting

Not quorate, leave for future meeting.

4         Discussion of Requirements Issues:

Issues List: (From Mark Goodner):



Junichi, from NEC sent the following email, on requirements issues:


4.1      Rel-9 Pull Model:

Iwasa stated that Fujitsu does not want to preclude the Pull model, but they will go with the consensus of the group on this.


Doug Bunting stated he was not in favor of it being a requirement for the first release.  It should be out of scope for the first release.


Sunil stated he agreed with Doug.  He is not sure if this group is going to do a lot of Http bindings.  Our application level programming should be with established MEP.


Consensus is to not include as requirement for initial specification.


No opposition in straw poll, tentative resolution to Rel-9 issue (pending) is to not include pull model as requirement.

4.2      REL-7 Backwards compatibility

Given a sender which is WSRM compatible, can a non reliable soap node interact with a reliable soap node.  This impacts the must understand aspects of the headers. 


Reliable messaging requires a reliable sender and a reliable receiver.


Is a non reliable receiver required to respond with an error?


Sunil stated receiver should send a fault message in this case.


Payrits stated this is too strong a requirement.  It might be enough to ensure that the receiver knows that the sender wants it reliable.


Bob stated that the behaviour is different if the sender has to deal with receivers which are not reliable message processors.


Consensus was reached on the following requirements level statement.

“Reliable sender needs to know it is not dealing with a reliable receiver.”


Action Item: - Doug agreed to craft appropriate wording. He will post to the issues list as pending resolved..

4.3      REL-25 Compatibility

Include a requirement as follows: The spec should be usable with other open standard technologies, if appropriate.


Tom Rutt asked if we should explicitly deal with WS Security.


Payrits stated that the schema should be able to be extended by an ID element for Digital signatures.


Bob stated that the mechanism to secure a reliable message should be the WSS mechanism.


Payrits stated that our WSRM spec needs to be able to work with WSS. 


Pete Wenzel, who is in the WSS group, stated that our protocol should be compatible with the WSS Specification.


Doug Bunting would appreciate further clarification as to what portion of WS security is encompassed.  E.g., do we do time stamps their way. 


Sunil stated we need to get more detail.  They want to see how big the job is before.


Doug stated the better requirement level statement is:

“Insure that ws reliability is usable in combination with WS security to implement secure reliable messageing.”


Include this new statement after the previously agreed statement:

The spec should be usable with other open standard technologies, if appropriate.


Concensus was reached on these requirement statements.


Editors should make this a pending resolution for this issue.

4.4      REL-3 Non HTTP Bindings

The following Requirement statements were proposed:

Spec must have an HTTP transport binding.

Spec must not precluded other transport bindings.


Consensus is to have pending closure of this issue with these two statements.

4.5      REL-30 Determine protocol feature support for each side

Related to Rel-7, the fallback issue.


The fault should indicate that it is not a reliable receiver for a particular protocol feature.


Currently the protocol responds with fault if sender wants unsupported features.


Payrits stated relying on faults alone can leave problems.


Tom Rutt stated that the protocol has to have faults to cover the cases.  He expressed concern that defining a new negotiation protocol is out of scope for this TC.  However the group might provide things like t-model values for use with UDDI to advertise reliable messaging capable ports.


Payrits stated this would be perhaps a later extension to WSDL, but it is out of our scope.


Doug Bunting stated it does not matter whether wsdl changes.  We can just use the extensibility mechanisms. 


Doug stated there are a number of steps before we could define our own negotiation or discovery mechanism.


Bob stated that persistence might be negotiated.  Tom Rutt explained that this was discussed and dismissed at F2F.


There must be faults to indicate a receiver (which is aware of the protocol) does not support protocol features.


Doug stated that what we stated in Rel 7 is enough.


In the protocol this could be satisfied using the must understand mechanism for our soap headers.


We should also have protocol specified faults defined for the case of the receiver understanding but not supporting specific features of the protocol.


Concensus reached that we do not have a specific requirement for negotiation protocol, outside what is required to satisfy Rel 7.


Editors should document Pending closure on this issue.


4.6      REL-42 Ack and duplicate elimination

Magdolna stated this is a spec issue.

Concensus reaced on reclassifying this as spec issue. 


Agreed to try to resolve this as a spec issue.


Junichi email states that we resolve that the receiver always sends the ack, even if it is a duplicate.


Doug bunting agreed in principal.


Consensus to close spec issue by having new specification text to clarify that the receiver shall always send the Ack even if the message is a duplicate.


Consensus to close as pending resolution.

4.7      REL-44 Duplicate elimination and time to live

Consensus reached that this should be reclassified as a specification issue.


It was stated that the most conservative solution is to resend, let duplicate elimination be responsibility of receiver.


Doug Bunting stated we should have an error for expired messages,  which could be used in this case.


Magdolna stated the sender may retransmit original message just before it is ready to expire.  How can sender know if the receiver received the message.


If receiver sends an error with the message ID in it would be good..


Look at WS-Reliability 1.0, and have email discussion on this as a spec issue.


Consensus of group to leave open as specification issue.

4.8      REL-48 Multicast

Consensus of meeting was to close this issue with no action.


No requirement to support multicast in the first release of the spec.


Consensus reached on Tentative closure, with no action.

4.9      Soap-1 Soap 1.2 Compatibility

Doug stated we would have to rewrite our spec in terms of infoset.


Sunil stated quite a few vendors already have soap 1.2.  He stated that we should include it.


Bob stated that most of what is beyond Soap 1.0 is beyond some toolkits. This is because Soap 1.1 is needed across  all components of a system.


Bob suggested leaving this issue open, waiting until Soap 1.2 closes to determine its impact.


Doug stated this should be classified as an open requirements issue.


Concensus was that this should be classified as a requirements issue

4.10Rel 33: Re-address Semantics of Acknowledgement

Mail from Junichi:

Acknowledgement Message


There are alternatives of the Ack semantics. I would list (1)-(4) as follows.

The proposal in f2f was (2), but I propose (1).


(1) [Ack for message persistance responsibility]

The receiver has received the message and the sender is no longer responsible

to preserve the message (i.e., the receiver now has responsibility for message persistence).


(2) [Ack for deliverability to the destination application]

The receiver has received the message and made it available to the destination application


(3) [Ack for delivery to the destination application]

The receiver has received the message and has delivered it to the destination application

(the message may not be processed by the application)


(4) [Ack for processing by the destination application]

The receiver has received the message and confirmed that it has been processed

by the destination application.



The difference between (1) and (2) is non-trivial when the message is ordered.

Suppose the message M2 should follow the message M1, M1 has lost, and M2 has been received by the receiver. In this case, "the receiver has received the message M2, but it is NOT available to the destination application." If we take (2), the receiver does not send Ack(M2) until it receives M1. Thus the sender needs to resend M2 although it is already preserved by the receiver.


Apparently, (4) should be achieved at the application level (using e.g. WS-Transaction?) instead of the WS-RM level.


If my understanding is correct, ebXML MS takes the meaning (3). But it is because the MS is tightly coupled with the application (ebXML) layer. In the f2f meeting (2) was proposed instead of (3) since how to deliver to the application is platform dependant.


I prefer the minimum semantics (1).


Doug stated we need to consider the bandwidth constraints. Alternative 1 as the better semantics.


Bob also agreed that alternative 1 is the better semantics.


Consensus of call is to change this proposed resolution to be alternative 1):

(1) [Ack for message persistance responsibility]

The receiver has received the message and the sender is no longer responsible

to preserve the message (i.e., the receiver now has responsibility for message persistence).


5         Discussion of Specification issues

(also in Issues list from Mark Goodner)


Chair Asked for further email discussion to get closure on these issues.


In particular, the chair pointed out a need to focus on resolving Rel-36, overlap of MessageID and GroupID/SequenceNo.



6         Discussion of Editor’s Draft Requirements Document



Chair asked the TC members to review the document, and provide comments.
Meeting closed at 7:24 PM EDT.


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