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 wsrm conf call - 7-15-03

Attached are the prelim minutes.

If you have any corrections post them before next Monday.  I will post 
the final
minutes next tuesday.

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


Preliminary Minutes WSRM TC Conference Call – July 15, 2003



The next meeting of the WSRM TC will take place by teleconference this

Tuesday July 15, 2003, from 5:30 to 7:30 PM Eastern Daylight Time

(UTC - 4)


The call in details are as follows :


Dial-in numbers:


Toll Free - : 1-800-605-5167

International - : 1-719-457-0339

Passcode: 732072


The draft agenda was send on the list.


1         Roll Call

First Name

Last Name




Voting Level





Booz AllenHamilton






Choreology Ltd






France Telecom











TC Chair





































Mitre Corporation
























Sun Microsystems






webMethods, Inc.



Meeting is Quorate.


2         Minutes Discussion

2.1      Appointment of Minute Taker

Doug Bunting will maintain the issues list resolution.


Tom Rutt will take minutes

2.2      Approval of previous meeting minutes


7/1/2003 Teleconference minutes:



Sunil moves to approve both minutes.  Jishnu  seconded.


No opposition, minutes approved.

3         Discussion of Issues:


Issues List: (From Mark Goodner):




3.1      Issues 36

Doug stated the issue resolution, from minutes was not clear.


The email discussion was not complete.


The resolution seems like it was arrived at without complete discussion.


Doug stated he can live with the resolution, he would like a better understanding about using sequence number outside.  It affects the persistence rules, for receiver forgetting overall group ID.  Not just message Identifiers.  This optimizes our protocol for ordered delivery, with a linear.


Tom Rutt stated that the message would be the pair group ID and sequence no.  Sequence number could always be zero if you did not want to support ordered delivery.


Doug stated the persistence rules are different with this proposal.


There is a need to fix our persistence rules, given there is not description about when the group ID can be forgoton.


Agree to add a new issue on the persistence requirements with the new paired ID.


Doug will put this new issue in.

3.2      Issue 44.

Duplicate interaction vs time to live.


The sender should not use message id is the resolution.


Doug stated the issue was closed with a resolution which does not close the issue.


The resolution of Issue 44 should point to 50.  There is still an issue on the semanics of time to live.


Doug suggested we quickly look at the unassigned issues, to see if people are interested.


3.3      Rel 16

Order and sequencing.


How long should a recipient hold onto out of sequence messages.  Rel 11 and Rel 6 references.


Iwasa did not change the description about the message id.


Requirements on holding out of sequence messages.


Iwsastry to eliminate the usage of the message ID in the text.


3.4      Rel 22


Another issue which came from original spec.


The word optional is used in ways that do not correspond to the RFC.


Optional in to implement vs optional in message


Go to email.


3.5      Rel 27 and Rel 28

Rel 27

Unassigned.  Receive cannot accept incoming connection.


Rel 28


Both of these are design issues which refer to abstract sections of spec document.


We have no words to explain this.


We could require a specific error response.


Propose to close these two issues on next call, unless there is further discussion.


Might be resolved by not having pull model.


3.6      Rel 29 Mandatory Features of Protocol

We may have to wait to see what protocol is.


Post resolutions proposed on this on the email.


3.7      Rel 31

Meaning of guarantee must be defined.


Might be resolved by rel 05.


Doug does not understand the issue.


At what point do you allow the infrastructure to state that it cannot deliver the message.


There is an issue on what happens when the system fails and the protocol cannot be met.


Eg, the PC crashes and loses its message ID persistence, it cannot assure duplicate elimination.


Peter stated that reliable systems do crash permantly, there is a problem defining when you give up, because one partner is not playing any more.


Jishnu stated you cannot mask all failures.


The failure modes of the implementation are part of the contract between supplier of wsrm and its user.


Doug – the duplicate elimination is a problem case.  Do we need an error to describe this.


Jeff M - We need to document what the limitations are.


Peter F – you cannot define the exact error message to use in all cases.


Tom R – you do not know who to tell when you reboot that you have lost your message ID persistence.


Doug asked if anyone can provide text regarding the failure modes.


Peter Furniss volunteered to come up with some proposed text.


3.8      Rel 32 – add new terms from requirements


This is an action item on Iwasa as priority editorial.


3.9      Rel 35 Order of header processing

Scott Werden raised spec issue.  Header processing order, particularly with wss.



Jeff M suggested we defer this issue for a few months.


This depends on marketing etc on how widespread soap 1.2 is.


Payrits proposed that we should support soap 1.2


Tom Rutt asked if this will cause a delay in the publication of our spec to do things both the soap 1.1 way and the soap 1.2 way.


Payrits stated that this will not be a big problem.  He stated we could have one set of schema compatible for both soap 1.1 and 1.2.


Payrits - The current wss uses soap 1.2.


Payrits – soap 1.2 should not be a mandatory implementation requirement.


Doug B – does the spec have to be rewritten using xml infoset terms.  Our input document is not.


Payrits stated that use of infoset terms is not required for use with soap 1.2.


Jeff M stated that the wss spec supports both.


Jeff M stated we need to see how it will impact the specification before we decide.


Doug B stated Sun does not want us to make implantation of soap 1.2 a requirement for doing wsrm.


Whether we publish a spec that supports soap 1.2 as well as soap 1.1 is the real issue.


Doug B asked Payrits to let us know what the minimal changes are to publish a doc to work with both soap 1.1 and 1.2.


Payrits took action to investigate what is required.  We need to leave the issue open.


3.11Rel 21


Three proposed resolution, not yet discussed on email list.


1. Clarify definition of from and to as they relate to WSRM and make them required elements.

3.1.1. From Element
The REQUIRED From element is used to specify the original sender node of the message. This is used by the WS-RM layer to unambiguously identify the original sender as there may be higher level addressing or routing schemes in place that have delivered the message to the current receiver node making the true origin of the message ambiguous to the current receiver node. The From element identifies the initial sender's endpoint to send the Acknowledgment or Fault Message to when the ReplyTo element in the ReliableMessage header is not present.
The value of this element MUST be a URI as defined in [RFC 2396].

3.1.2. To Element
The REQUIRED element is used to specify the ultimate receiver node of the message known to the sender.
The value of this element MUST be a URI as defined in [RFC 2396].

2. Keep from/to optional and clarify definitions.

3. Remove from/to.


We need to talk about this further.


Action to Iwasa to justify why we need this in the spec, even as an option.


If it not justified, we can remove it at the next meeting.


3.12Rel 39 Reply to element

Why is it mandatory even if callback ack binding pattern is not used.


Clarify definition:

3.2.2. ReplyTo Element
This OPTIONAL element is used to specify a different endpoint than the initial sender to reply to with an Acknowledgment or Fault Message. Higher level addressing or routing schemes MAY supercede the value of the From element when ReplyTo is not used to indicate the endpoint to receive an Acknowledgment or Fault Message. Higher level addressing or routing schemes MUST NOT supercede the value of the ReplyTo element when it is used.

The value of this element MUST be a URI as defined in [RFC 2396].


Doug B stated that the proposal is to make it optional.


Payrits stated it could be worded in a simpler way.


Payrts – can just state it is optional for message instance.


Proposal is to make cardinality is 0 or 1.


If sender is demanding ack on response, there is no need to include it in the request.


Doug B, the application might send a business response to the callback.


Tom Rutt suggested that we might make this optional, with it being required when the callback ack pattern is requested.


The resolution needs to be updated to use the proper language.


Need to ask for a correctly worded proposal, that takes all into consideration.


Doug asked if anyone wants to volunteer to come up with better wording.


Tom Rutt volunteered to come up with text to resolve this issue.


3.13New spec Issue Rel 51


Payrits proposed to add a new issue of piggybacking of acknolwledgments.


He has an email which describes this.


Payrits should send Doug the URL for the email from the list tomorrow.


3.14Rel 46 

Nobody is responsible with no proposal.


Sunil took action item to come up with a proposal for this. 




4         Discussion of Editor’s Draft Requirements Document




Payrits stated it is complete as of the agreements we have accepted.


Try to have comments to the list by two weeks.


Doug asked that Payrits send a list of what issues have been addressed.  We can make motions to accept the proposed text at the next meeting.


Any problems with the text should be discussed on the list before the next meeting.


Paolo stated on page 10, R5.2 backward compatibility.  Reliable sender needs to know it is not dealing with a reliable receiver.


Payrits stated this wording could be improved.


Paolo stated the WSDL could be used to discover how it is dealing with a reliable receiver.


Doug B stated there are a number of issues which are related.  The original issue was rel 7 which was resolved.  The Issue on wsdl requirement in the previous version of the requirements list, and in our charter was resolved as too much work and removed.


Rel 50 states we recognize this is an issue, and will have text that it will come back later.


The two ways wsdl can be used in our spec.  One is to describe how a sender learns a-priori what a receiver can do wrt wsrm.  Another way is to describe headers to describe reliability.


Sunil stated Rel 7 was closed, as to why dealing with binding part was the problem with wsdl.  However we agreed to do non-normative text using documentation schema.


There is a new issue 49 open on how to use documentation schema.



Describe how headers are used in soap message Add way to describe our protocol

Add way to identify that a service is RM capable.


Sunil clarified that it is the second one that Issue 49 is focused on.


Doug asked if the annotation will be for subparts of the protocol.


Sunil stated that the details are subject to discussion, on how granular we should go.  Sunil wants to take a cut before the discussion.


Payrits stated that Rel 07.


Paolo stated that using wsdl is important.


Tom Rutt stated that issue 49 is still open



5         Discussion of Possible Schedule for Specification Completion

Iwasa started the discussion on how to progress the new spec document.
Some issues were resolved, but there is no consideration of how to describe in the spec.
Email discussion on the need for further discussion
Iwasa agreed to send a separate email out to start discussion on how to get proper text regarding a resolution.
Doug asked how we distinguish issues which are closed as agreed, in distinction to those which have been placed in the document.
Doug will add new status for issues which have actual text in the document.  
There is another state which is an interim state of a text in wordsmith.
In order to make progress we should have the document in good shape by the September f2f.
Try to have some text for every issue resolution by that time.
Bob stated that the f2f can be used to get agreement on text.

6         Decision on start times and end times for September f2f.

September 3, 4, 5, in Boston area was agreed on last call.
Starting time for meeting on Wednesday, 8:30 Am each day, Close by 5:30 on wed thurs.
Close before lunch on Friday.
Dock agreed to send out a meeting announcement with these times.
Lunch on our own in the cafeteria.



The meeting adjourned at 7:20 PM EDT.

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