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 meeting - 9/30/03

The prelim minutes are attached.

Please post any requested changes before Thursday PM.

Tom Rutt
WSRM Chair

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 September 30, 2003



The meeting of the WSRM TC took place by teleconference 
Tuesday August 30, 2003, from 5:30 to 7:30 PM Eastern Daylight Time
(UTC - 4)
The call in details were as follows :
Dial-in numbers: 
Toll Free - : 1-800-605-5167 
International - : 1-719-457-0339 
Passcode: 732072 

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call  Sept 30, 2003
 1 Roll Call
 2 Minutes Discussion
 2.1 Appointment of Minute Taker
 2.2 Approval of previous meeting minutes
 3 Discussion of Issues:
 4 Discussion of Interop Demo at XML show, and status of Subgroup
Discussed interop demo before issues.

1         Roll Call

First Name

Last Name








Booz Allen Hamilton





France Telecom














TC Chair


























Mitre Corporation





NEC Corporation





NEC Corporation













































Sun Microsystems





University of Hong Kong





WRQ, Inc.


Meeting was quorate.


2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Mark Goodner agreed to take issue resolutions.


2.2      Approval of previous meeting minutes


Boston f2f minutes:

Sunil moved to accept the minutes. Iwasa seconded.
No opposition, minutes approved.

3         Discussion of Feasibility Demo Activities

3.1      Proposed charter

Mail from Bob Freund:


Draft Charter, WS-RM Interoperability Demonstration Sub-Group



The WS-RM Interoperability Demonstration Sub-Group is designed to:

1.      Provide a forum for implementers of the WS-RM specification, to meet and demonstrate interoperability across implementations.

2.      Provide test tool standards, specifications, and test case definitions for participants engaged in interoperability demonstrations of WS-RM implementations.

3.      Provide specific feedback to the TC regarding WS-RM implementation experience and specification issues as may be discovered.

4.      Provide proof of concept and demonstration capability for the promotion of this specification.



The following are expected to represent deliverables associated with this sub-group:


Demonstration Scenario Collection

This is a collection of demonstration scenarios and specifications designed to exercise one or a combination of protocol features. The collection will be revised and refined from time to time

Demonstration Post-Mortem

This report documents the collective experience of the implementers engaged in a interoperability demonstration. Topics that will be covered include any specification inconsistencies or misleading wording that presented difficulties to the implementers. Issues will be related to the reference specification utilized in the interoperability demonstration and commentary will note issues that although present in the reference specification appear to be corrected in some subsequent committee draft specification superceding the reference specification.

Demonstration Tools

Although the mechanism to be used for the distribution of contributed tools has yet to be established, it is the intent of the sub-group to generate, revise, and refine a set of such Demonstration Tools from time to time and to distribute those tools to participant of Interoperability Demonstrations



Alan moved to approve the charter of the new group. Jeff M seconded.


Jacques stated Sub committees need a statement of purpose. They do not really need charters, and it does not need Oasis approval.


Doug B asked that he would like time to read this email. He asked what the deliverables are.


The tools delivered would be things like the trouble maker.


They would be made available to other participants by those that make them available. The way to do the distribution would have to be resolved by this group.


Jacques stated the subcommittee deliverables are only to the TC. Any other deliverables would have to be done by the TC.


These SC deliverables are to the TC members, not to the outside world.


Jacques stated he liked this as a statement of purpose for the TC.


Change the title to Statement of purpose.


Nobody opposed to title change.


No opposition, subcommittee has been formed.


Check how mailing list is set up.


Bob F will check to set up what is needed in Kavi.


Bob F and Jacques were nominated as co-chairs.


Nobody opposed, Jacques and Bob are co chairs.


3.2      Demo at XML show

Demo has to be a committee draft.


Jamie Clark stated there are three criteria for the XML 2003 conference:

  • List of participants, three or more
  • Agree to scenarios well in advance of demo
  • Normally a 1.0 CD is what they expect to see at these demos.


Bob Freund talked to Jamie on this, who stated a dot level of CD is all that is required.


Jeff M: demo is W3c and Oasis. Will the other group be allowed to demo their stuff?


Jamie stated Oasis has been subcontracted to organize this demo. That is why they want CD status to level playing field.


Tom stated we could have a 0.8 draft out of the face to face meeting. This is on our roadmap already.


Doug B stated they are not really rules.


Bob Freund stated there could be moving parts in the spec, however the demo should be based on stable agreements. Part of the reason for the demo is promotion of standards activities. They want a committee jure specification.


By the time the demo happens, we would need at least a 0.8 committee draft. They would like to get to 1.0.


The main open things polling/status and request/response.


Bob F stated that they should stay clear of poll/status and request/response in the core spec.


Jacques stated that there are some features which need to be cleared up, with the agreed features. However we could have an early CD for ballot, which is not complete.


Tom Rutt stated that this puts pressure on us to take a vote, before the demonstration.


Alan stated we should focus at the f2f on getting the current features stabilized.


We need volunteers to work on improving the text in the documents.


4         Discussion of Issues:

Latest issues list at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3529/wsrm-reqm-issues.html


4.1      Rel yy Use of Sequence Number outside of Ordered Delivery

Mail from Jacques:

I would like to summarize what I believe the "amended RelYY" proposal is

currently, so as to make progress on submitting it, as it is one of these features

that is on the critical path of implementors...


- There will be three ways to "sequence" (or not) messages within a group:


(1) when ordering is required:

GroupId + SequenceNumber(with status) + MessageOrder (empty subelement of requestheader as all the others are)


(2) when ordering is not required, but for other benefits

(here the possibility of fast/space efficient duplicate check)

GroupId + SequenceNumber(? optionally with status)


(3) when ordering is not required, but no other use of sequences is desired,

there will be only one message per group, identified by group Id:

GroupId (and no SequenceNumber element)



- each GroupId is globally unique.

- in both cases (1) and (2) SequenceNumber values must be unique within a group,

and generated as a contiguous sequence (modulo...)

- in both cases (1) and (2), the status attribute on SequenceNumber is allowed values

"Start" "Continue" "End" according to similar rules. (does Doug agree here?)


NOTE1: Sunil did not reintroduce MessageOrder in his latest schema yet.

I personally favor this over a lower level way to signal the Ordering feature:

it is more consistent with what we do with AckRequested and DuplicateElimination.


NOTE2: Along the line of what are the rules in using combinations of header elements:

Since the Ordering feature applies to an entire group, and that it is no longer

signaled by the presence of SequenceNumber under this proposal,

should we consider significant the "MessageOrder" (or whatever signal)

in the first message only of the group?

(or few first ones in case we need to handle the special case of the first one missing / delayed)

otherwise, if we keep a per-message semantics, having a mix of messages with/without such signal

should NOT be allowed in a group. And the question extends to AckRequested and DuplicateElimination,

since these two features are required with Ordering.




Doug B stated that ordering and providing a sequence number are not completely orthogonal. When you do ordering , the sequence number is required..


This requirement is just text.


Doug B stated he would prefer the requirement is enforced in the schema.


Group ID is required, sequence number is optional.


Reply to must only exist when pattern in callback. Sunil stated we have already have these kind of cross requirements.


Sunil stated he prefers to put reliability features requested in RequestHeader. It is a clear abstraction.


Tom asked why the sequenceNumber could not be mandatory.


Sunil stated how we would distinguish sequence numbers which are independent from ordered messages.


There is an overhead cost in maintaining groups. In such cases you could just use group ID.


The other alternative is adding start and end as a status. This is a single identity scheme, identity plus group number.


Sunil: Why do we need to send it if it is not needed. Sending a value that is ignored is not good. The only advantage is to help the schema.


Sunil does not want the value to signal any special features.


Remove after in group ID. Group ID is mandatory. This is an orthogonal issue.


New Spec issue on semantics RemoveAfter attribute of Group ID.


Payrits had question about the text for grouping of acknowledgement. Jacques clarified that this is not part of this motion.


There are open Spec Issue on multiple acknowledgements mechanisms, Rel 74 and 75.


Sunil moved to accept the proposal of Jacques, Jacques seconded.


No opposition motion passed.


Instruct editors to updated the text and the schema as well.


Sunil agreed to get a proposal for the semantics of RemoveAfter attribute, Jacques will participate.


4.2      Multpiple acks proposal.


Payrits stated that ack should be legally binding proof that message is sent. Optimizations can be used.


Bob F asked if he was talking about non-repudiation.


Parits stated we should keep it in mind.


Bob F also asked about message mining.


Jeff M stated we should stay away from legally binding areas.


Iwasa had a proposal to change the syntax of the ack response.


Iwasa volunteered, Payrits agreed to participate in the proposal.


The will send a proposal to the group before the next meeting.


4.3      Schema comments

Payrits asked why the Any is there.


Scott stated this is for extensibility.


Payrits stated there are problems with Any, but he can accept if the group is happy.


Name of the response vs acknowledgments.


Finalizing names will be delayed to the face to face meeting.


Sunil stated to send him mail on any problems.


Sunil had some editorial concerns.

4.4      Poll Mechanisms

The main issue is whether the Poll should be a wsdl operation bound to the body of the message.


Doug B stated the wsdl allows a definition to be pointed at by multiple endpoints.


Tom Rutt asked about whether the wsdl operatio for poll would be in the same port type with the data. It could be in a separate wsdl port type, bound to a different url.


There are problems with binding two services to same URL.


Given a WSDL approach for poll, Should we allow both scenario:

1)      the Poll operation is combined in a port type with the application operations:

2)      The poll operation is in a separate port type which is bound to a separate url from the application port type.


Sunil stated that the combination of operations is difficult since there is no port type inheritance.


The second scenario requires exposure of the RMP as a separate service.


Sunil stated that WSDL 1.2 has an interface attribute, all ports on url have the same value.


Sunil stated reliability is not a service by itself, once it has a wsdl it is exposed as a service. It is a quality of service.


John Fuller stated that there may be other headers to use outside of reliability. We could use these existing services instead of polling if feasible. This is status of an individual message.


The wsdl approach seems to make one have to describe the poll in the wsdl.


Doug B stated that we could define the wsdl once, which is referred to by other wsdl documents.


Doug is not certain why we are not talking about the protocol being described. When you are doing the status check can you reuse MEP from soap or do we have to reinvent them.


Doug stated that the protocol should remain silent on whether the poll is sent as its own reliable message.


To put in the body, we would have to deal with the binding issues (which might be

Covered by wsdl annotations).


John Fuller asked if the RMP is directly addressed as URL.


The service endpoint has both the RMP processing and the Body processing.


Option 1 ( combined in port type) might be useful to turn on or off, for specific endpoints. If it is global option 2 might be better.


Sunil stated option 1 is a combinatorial nightmare.


Mark G stated he liked option 2.


Sunil stated he prefers the poll be in the header.


WSDL annotation issue is orthogonal.issue, since it is optional.


Sunil stated that the fault issues from Doug regarding a header can be dealt with.


Sunil stated there is a piggybacking issue which is made easier using a header. The body is meant for application payload. Once we open this up, the RMP has to open the body, and is swept into dealing with all the issues we have brought up on the WSDL.


Sunil stated he does not see the poll as a different body. For the callback we are sending headers, and sending a poll as a header in the reverse direction is symmetric.


Sunil stated that dealing with headers is that the endpoint can do this in the wsdl (bind the header elements to the soap header) but they do not have to do that.


Doug B stated that other soap extension specs have defined both headers to add annotations or metadata, and also specify protocol elements as soap body elements, to find info about tokens in the headers.


Example it to add SAML token to message, receiver has option to use SAML protocol to validate that token.


Doug B stated that the headers would require additional faults.


They have centralized WSDL document to describe the protocol.


Payrits stated the problem is not header vs body, the question is to reuse soap MEP or define our own.


Payrits stated that if we do headers, we have to redo all the work that was done by Soap and WSDL.


Payrits stated that if it an operation, we can either use soap or do our own. If the poll is an operation this can use the soap MEP.


Peter from Oracle: If it involves the wsdl it affects deploying the web services.

Even if you import a central wsdl document, you would still have to include it in a deployment scenario.


Peter stated the time to live scenarios may make it hard to implement as a separate service endpoint.


The reliable handler is not easy to implement as going with the wsdl for the poll.


Peter stated there are already rules in soap for header faults processing.


Payrits stated the only rules for header faults is that they must occur back in the return message header.


Practical question how do you do deal with the deployment of an orthogonal WSDL for the polling operation


Peter: How is the URL from orthogonal RMP service communicated to the Client of the original request.


Jacques: Scenario 1 seems unthinkable as a requirement for a business app


If we are going to use wsdl, we are most likely in scenario 2 world.


Jacques stated we are opening a can of worms using the wsdl level solution.


Jacques stated the conservative approach is to use the header based approach.


Jacques would like to see the use case for polling.


Continue on email. Sunil will clarify the use case to justify the polling.


4.5      Rel Reliable Request/Response Proposals

Mail from Jacques:


Here is a tentative summary of the reliable request-response proposal I have sent

a couple of weeks ago ( co-signed Marc G., Sunil K., Payrits S., Jacques D.)


Because it is a big chunk, we 'd like to get feedback first on the overall direction of the proposal

(summarized below).

Then there are still some details left to be discussed.






General recommendation on what WS-R should cover regarding Guaranteed delivery (GD)

of messages involved in a WSDL request-response :


1- Only the following GD cases should be supported by this version of WS-R:

- GD of request + GD of response (Variant 1)

- GD of request + no GD of response (Variant 2)

The following case should be excluded (not covered by this specification) (see Option 3.1.1):

- no GD of request + GD of response (Variant 3)


2- The recommendation for GD of request-response, is that its use of Ack and resend procedures

will differ from one-way ops in the following way:

- request-response is treated as a single transaction (will be entirely replayed, if either leg failed)

- in case of Variant 1, in case the response is not acknowledged, the request-response should not be replayed.

Instead, the Ack should be resent (see Proposal 1.2) (depending on firewall restrictions on either side,

either using RMP-level polling to get the Ack, or a resending mechanism for Acks.)(to resolve!)


3- Given the impact of supporting GD request-response on SOAP implementations (seee Appendix A),

recommendation is that it should belong to a higher conformance profile for WS-R.

i.e. some implementations that cover only the reliability of one-way operations

should still be considered as conforming at some level to WS-R.


There was no time to discuss this, it will be discussed on the next call.


People are requested to discuss this proposal on the email.


5         Future meetings

France Telecom Research will host the next FGF

October 28-30, 2003, in South San Francisco.


Agreed to start start at 9 on Tuesday and go to 5 every day.


Have all three days for meetings.


Meeting in South San Francisco 801 gateway blvd.


Pramilla agreed to send out the notice, with all the details.


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