Minutes OASIS WS-RX TC Weekly Conference Call

 

Date:  Thursday, 14 July 2005

Time:  01:00pm - 02:30pm PT

 

0         Conventions

Minutes Style Conventions

 

Motion text

 

§    Motion Resolution text

 

Ø  Action item text

 

Ø  Potential new issue Text:

 

Tom Rutt agreed to take the minutes.

1         Roll call

 

Roll Call:

First Name

Last Name

Role

Company

Alexander

Leyfer

Voting Member

Actional Corporation*

Charlton

Barreto

Member

Adobe Systems*

Duane

Nickull

Prosp Member

Adobe Systems*

Lei

Jin

Voting Member

BEA Systems, Inc.*

Dave

Orchard

Voting Member

BEA Systems, Inc.*

Gilbert

Pilz

Voting Member

BEA Systems, Inc.*

Ian

Jones

Applicant

BTplc

Peter

Furniss

Voting Member

Choreology Ltd*

Andreas

Bjarlestam

Voting Member

Ericsson*

Nilo

Mitra

Voting Member

Ericsson*

Jacques

Durand

Voting Member

Fujitsu Limited*

Kazunori

Iwasa

Voting Member

Fujitsu Limited*

Tom

Rutt

Secretary

Fujitsu Limited*

Robert

Freund

Voting Member

Hitachi, Ltd.*

Eisaku

Nishiyama

Voting Member

Hitachi, Ltd.*

Nobuyuki

Yamamoto

Voting Member

Hitachi, Ltd.*

Doug

Davis

Voting Member

IBM*

Christopher

Ferris

Voting Member

IBM*

Paul

Fremantle

TC Chair

IBM*

Daniel

Millwood

Observer

IBM*

Peter

Niblett

Applicant

IBM*

Rebecca

Bergersen

Voting Member

IONA Technologies*

Stefan

Batres

Voting Member

Microsoft Corporation*

Paul

Cotton

Voting Member

Microsoft Corporation*

Colleen

Evans

Voting Member

Microsoft Corporation*

Marc

Goodner

Voting Member

Microsoft Corporation*

Christopher

Kurt

Voting Member

Microsoft Corporation*

Jonathan

Marsh

Voting Member

Microsoft Corporation*

Jorgen

Thelin

Voting Member

Microsoft Corporation*

Asir

Vedamuthu

Applicant

Microsoft Corporation*

Chouthry

Palanisamy

Voting Member

NEC

Abbie

Barbir

Voting Member

Nortel Networks Limited*

Paul

Knight

Voting Member

Nortel Networks Limited*

Lloyd

Burch

Voting Member

Novell*

Steve

Carter

Voting Member

Novell*

Martin

Chapman

Voting Member

Oracle Corporation*

Sumit

Gupta

Voting Member

Oracle Corporation*

Anish

Karmarkar

Voting Member

Oracle Corporation*

Ashok

Malhotra

Voting Member

Oracle Corporation*

jeff

mischkinsky

Voting Member

Oracle Corporation*

Greg

Pavlik

Prosp Member

Oracle Corporation*

Heidi

Buelow

Voting Member

Rogue Wave Software*

Michael

Bechauf

Voting Member

SAP AG*

Sanjay

Patil

TC Chair

SAP AG*

Vicki

Shipkowitz

Voting Member

SAP AG*

Claus

von Riegen

Voting Member

SAP AG*

Steve

Winkler

Voting Member

SAP AG*

Umit

Yalcinalp

Voting Member

SAP AG*

Blake

Dournaee

Observer

Sarvega

Pete

Wenzel

Voting Member

SeeBeyond *

Giovanni

Boschi

Applicant

Sonic Software

Dave

Chappell

Voting Member

Sonic Software

Glen

Daniels

Applicant

Sonic Software

Vikas

Deolaliker

Voting Member

Sonoa Systems, Inc.*

Doug

Bunting

Voting Member

Sun Microsystems*

Ram

Jeyaraman

Voting Member

Sun Microsystems*

Dan

Leshchiner

Prosp Member

Tibco Software Inc.*

Shivajee

Samdarshi

Prosp Member

Tibco Software Inc.*

Prasanta

Behera

Observer

VISA International

Vadim

Furman

Voting Member

webMethods, Inc.*

 

 

79% voting members, achieved quorum.

2         Review and Approval of Agenda

Agenda            Agenda for this weeks call

 

1. Roll Call & Quorum

 

2. Review and approval of Agenda

 

3. Approval of the minutes of Prior meetings

 

4. Call in numbers for future calls.

 

5. Update on next F2F

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00065.html

 

6. Update from editors team

 

7. Update on the issues list

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml

a) accept new issues

b) review of issues list

c) discussion of issue prioritization

 

8. Action Item review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

9. Discussion of the following four issues:

 

Ø Potential issue a> Source based delivery QoS policy assertion

http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html

Ø Potential issue b> Destination to declare delivery QoS policies

http://lists.oasis-open.org/archives/ws-rx/200506/msg00046.html

Ø Potential Issue c> Granularity (per operation vs. per portType) of delivery QoS policies

http://lists.oasis-open.org/archives/ws-rx/200506/msg00053.html

Ø Potential Issue d> Single sequence to span multiple ports

http://lists.oasis-open.org/archives/ws-rx/200506/msg00059.html

10. Any other business.

Paul C wanted to report on the arrangements for the F2F in Redmond.

 

3         Approval of the minutes of Face to Face and Teleconf 7/7/05

 

Minutes of Face to Face meeting:

   http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm

 

Tom Rutt moved, Paul Knight seconded to approve face to face minutes.

 

§    No object face to face minutes approved.

 

Minutes of 7/7/2005 Teleconference:

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13536/MinutesWSRX070705-b.htm

 

Chris F moved to approve, Anish seconded.

 

§    No objection ,minutes of teleconf 7/705 approved.

4         Call in numbers for future calls.

Novel will host next two calls.  July 21 and 28.

 

Adobe will host afterwards.

5         Update on next F2F

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00065.html

 

waited for Paul Cotton to arrive.

 

Paul asked the chairs to have a KAVI ballot to determine who will come.

 

Ø  Actioin: Chairs should start a KAVI ballot asking members if they will attend the Face to Face meeting, either in person or by teleconference.

 

Paul Stated there will be a conference phone in the room.  He can provide a conference phone.

6         Update from editors team

Gil stated that the editors went thru the editorial issues, and posted a resulting set of editorial issues to the list.

 

Jeff had question about the repository.  Does the oasis policy apply.

 

Duane Nicol: they do not have such a facility yet.

 

Jeff: we need to be sure we do things according to the rules.

 

Marc G: the BPEL repository was set up by IBM, and transferred to source forge.  The just use it as a cvs repository.  Anything released is thru the oasis document store.

 

Jeff M: it is a little more complicated.  BPEL is under different IPR policy than ws-rx TC. 

 

Ø  Paul  F: Chair took  an action item to get a ruling from Jamie on CVS repository usage.

 

Steve W: we wanted a cvs repository to track the changes between versions.

 

Marc G: there are some problems with having everyone on TC to access the source forge CVS repository.

 

Peter F: members of BPEL have access to the repository.

 

Chris K: I would propose to ask the chairs to look into this and not spend time on it in the TC meeting.  Jeff M and I can work with OASIS staff to expedite the discussion.

 

7         Update on the issues list

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13598/ReliableMessagingIssues.xml

 

Sanjay ran the discussion: He asked Marc G to review the issues list.

 

Doug B expressed a concern that the document was not posted with the correct attributes.

 

Tom Rutt stated he did not get an html rendering in Firefox.

7.1      a) accept new issues

Marc G stated the new issues which came up this week were editorial, including the Editor’s issues.

Below are the new issues raised since the July 7th TC call and the July 14th TC call.

7.1.1      Title: typo in expires P0S

Description: per the schema spec a zero second duration needs to have the "T" designator - so it should be PT0S not P0S.
Justification: align with schema spec ( http://www.w3.org/TR/xmlschema-2/#duration )
Target: core
Proposal: simple search and replace of P0S with PT0S

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00046.html

§    No opposition to accepting as new issue

 

7.1.2      Title:  typo in Interop scenario 3.2 example

Clarification - the document is Interop Scenario 3, not the main spec. 

The section is at the end of 3.2

 

This one is an easy fix - the first example of a message had one visible

error - an extra white space after the two "--" of the comment.

 

|<!-- BEGIN: 128-bit key K encrypted using public key of SERVICE --

 >|

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00061.html

Concern expressed that this document is not a deliverable. Do not accept at this time as new issue.

 

7.1.3      Title: anonymous acksTo

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html

 

§    No objection to accepting anonymous acksTo as new issue

 

7.1.4      Title: Max message number in policy

Description: define a policy assertion that defines the highest message number the RM destination will accept.
Justification: without knowing in advance what the highest message number is the RM source may exceed it, causing the entire sequence to be terminated - when it may have been able to start a 2nd sequence to continue its work.  By allowing the RM source the option of terminating the sequence gracefully it can still deliver lost messages for the original sequence.  As it stands now, if the sequence is terminated the lost messages will not be resent.
Target: RM policy spec
Proposal: Define:
/wsrm:RMAssertion/wsrm:MaxMessageNumber
/wsrm:RMAssertion/wsrm:MaxMessageNumber@number - unsigned long

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00073.html

 

Doug B: I would like to have this issue deal with whether a system has to support unsigned long.

Chris F:  I would like to have a separate issue “Can implementation support less than unsigned long?”

Shivagy:: There could be another issue regarding support of types as a more general issue.

Chris F: the issues should be relevant to deliverables of TC.  We need to discuss at this level whether the issue is understandable.

§     Agreed to add this as an issue.

Shivagy: :  can raise a newer issue which raises his thoughts.

 

Doug B: some issues can be made irrelevant by resolutions of other issues.  I agree to move ahead with this issue.

Doug B can capture his issue.

7.1.5      Title: Document Names

Description: Should the “names” of the normative documents remain the same as the submission documents or should they be changed? This issue applies to both WS-ReliableMessaging and WS-RM Policy.

Justification: The “name” of a document effects a number of things such as the document identifier, URIs etc.

Target: core, policy

Type: editorial

Proposal: Preserve the name of the documents as submitted. Changing the names would increase confusion (already at a high level) around “OASIS and RM” and result in extra effort. There does not seem to be any reasons for changing the names forcefull enough to override these concerns. Therefore the names of the normative documents should be “Web Services Reliable Messaging Protocol (WS-ReliableMessaging)” and “Web Services Reliable Messaging Policy Assertion (WS-RM Policy)”

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00090.html

§    No objection to adding as an issue.

 

7.1.6      Title: Required Artifact Metadata

Description: OASIS guidelines (http://www.oasis-open.org/committees/download.php/13344/ArtifactIdentificationRequirements-v1.0-wd-15.pdf) require that the artifacts (documents, schemas, etc.) produced by a TC should have a minimum set of of metadata that describes these artifacts.

Justification: OASIS requirement.

Target: core, policy

Type: editorial

Proposal: We propose the following values for each specification:

WS-ReliableMessaging:

artifactName: TBD

tc: TBD

product: wsreliablemessaging

productVersion: 01

artifactType: spec

stage: wd

descriptiveName: Web Services Reliable Messaging Protocol Specification

WS-RM Policy:

artifactName: TBD

tc: TBD

product: wsrmpolicy

productVersion: 01

artifactType: spec

stage: wd

descriptiveName: Web Services Reliable Messaging Policy Assertion Specification

Note that the “product names” of these two artifacts differ.

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00091.html

§     Agreed to add as an issue

7.1.7      Title: Document Identifiers

Description: The artifacts (documents, schemas, etc.) produced by the WS-RX must be uniquely identified. We need to decide on the identifiers for WS-ReliableMessaging and WS-RM Policy.

Justification: Self-evident.

Target: core, policy

Type: editorial

Proposal: According to the OASIS guidelines and in light of the proposed artifact metadata, the documents should currently be identified as:

wsreliablemessaging-01-spec-wd-01.*

wsrmpolicy-01-spec-wd-01.*

Note that some identifiers may have the final sub-version removed. The “*” indicates that these documents may be formatted in either HTML (.html) or PDF (.pdf).

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00092.html

§    Agreed to add as a new issue.

7.1.8      Title: XML Namespace URIs

Description: We need to decide upon the normative XML namespace URIs that must be used by implementations of these specifications.

Justification: Self-evident.

Target: all

Type: editorial

Proposal: The namespace URIs for WS-RX-defined schemas should be URLs that resolve to RDDL documents that provide information about the schema as well as links to the corresponding specification(s). Per OASIS guidelines, the RDDL documents must be hosted by OASIS. Therefore the exact URL values will need to be co-ordinated with OASIS but, in general, they should look something like the following:

xmlns:wsrm=”http://www.oasis-open.org/committees/ws-rx/wsreliablemessaging-200507.html”

xmlns:wsrmp=”http://www.oasis-open.org/committees/ws-rx/wsrmpolicy-200507.html”

Note that the “200507” in the URL is represents the schema version as a date (July, 2005).

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00093.html

§    Agreed to add as a new issue.

 

7.2      b) review of issues list

 

The issue list was corrected so it renders in Firefox.

7.3      c) discussion of issue prioritization

Marc G: we might want to spend some time to decide which issues can be tackled first.  I have not attempted to do this yet.

 

Gil: I have a preferred approach to put requirements issues at the top of the priority.  This can save a lot of future effort if a requirement is not accepted.

 

Sanjay: we should give more time to come up with high level areas which pertain to the issues.  At future calls we can look at all the issues.

 

Paul F: at this time our main point is to capture as many issues as possible.

 

Sanjay I encourage TC members to bring their major issue to the table very soon.

 

Paul F: I suggest we work by email to prioritize the issues list.  Members should have email discussion, terminating on Monday morning, regarding which issues they want to discuss at the next call.

 

Bob F: we need to have short discussions to assign owners to each Issue.  The owner can lead the email discussions.

 

Paul F: I urge TC members to address their issue priorities to the list before Monday morning.

 

Paul F: the chairs  will post issues to be

 

Sanjay: TC members should send their issue priority discussion before Monday
morning, and the chairs will propose a list of issues for discussion by
Monday noon Pacific Time. If there are any further suggestions made by
the TC members, an updated list of issues for discussion would be posted
by the chairs before the conf call on Thursday.

 

 

8         Action Item review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

Paul F pointed out that the two KAVI ballots on proposed charger changes were initiated by OASIS Staff.

 

#0010: Add Four new issues a thru c from TC meeting 7/7/05

Owner: Marc Goodner

Status: Closed

Assigned: 2005-07-08

Due: 2005-07-14

 

#0009: Suggest Email Template for Proposed Issues

Owner: Marc Goodner

Status: Closed

Assigned: 2005-07-08

Due: 2005-07-14

 

#0008: Prepare First TC Issues List

Owner: Marc Goodner

Status: Closed

Assigned: 2005-07-08

Due: 2005-07-14

 

#0007: Sanjay to set up editing team Subcommittee or mailing list

Owner: Sanjay Patil

Status: Still Open

Assigned: 2005-07-08

Due: 2005-07-14

 

#0002: OASIS Staff should fix typographical error in charter of missing space between “produces” and “to” the next time the charter is updated.

Owner: James Bryce Clark

Status: Still Open

Assigned: 2005-07-06

Due: 2005-07-08

 

9         Discussion of the following four issues:

9.1      Issue 6  Source based delivery QoS policy assertion

http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html

 

Tom Rutt posted a new email to open discussion on this issue, as:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00108.html

 

Tom Rutt was assigned as owner of the issue.

 

Tom Rutt gave an overview of the email discussion.

Here is a more precise statement about the real issue at the core of i006 

 

"How does the RM Destination know which level of Delivery assurance to associate with a received message?"

 

We can't just discard this question as only relevant to the implementation space, especially if the assumptions below are valid:

 

- I expect an RM Destination to handle concurrently several sequences associated with different delivery assurances (DA) (driven by different WS operation requirements, e.g. InOrder or not, but also by SLA requirements, given the cost / overhead of RM)

- Even if we assume that some DA is statically assigned to an endpoint, a layered implementation (see discussion below) of the RM destination component should not have to peak inside the message body or other headers to figure the DA. RM Header data such as Sequence ID should be sufficient.

- Assuming all messages within a sequence as associated with the same delivery assurance (DA) (assumed in WS-RM Policy), it is not clear how the RM Destination associates a new sequence ID with a DA, when answering a SequenceCreation request from the Source.

 

Chris F: currently RM granularity applies to a port.  Currently there is no way to have different qos per port.

 

Chrif F : there will be a single sequence at a time per port typically.  But the spec is designed around the concept of one for one with port.

 

Chris F: the endpoint can implement a given level of delivery assurance. 

 

Tom R:  Even with qos per endpoint – there might be a need to have the reliable source and destination communicate their level of qos.  That is the point of the second bullet in the summary above.

 

Gill: there are runtime tradeoffs which the source may want to take away ordered delivery.  I do not see a real win with adding duplicate elimination.

 

Tom R: with the current ws-rm protocol you are correct that duplicate elimination adds no cost over guaranteed deliver, since it has to hold the entire history of which sequence numbers were already delivered.  However, ordered delivery requires message buffering.

 

Jeff M: Do we know what an endpoint is. Is it that identified by EPR.

 

Paul F: this is another complex point.

 

Paul F: we have ran out of time, lets take this discussion to the email list.

 

Umit: we need to have a better way to determine the meeting speaker queue.  Not everyone is on irc.

 

Ø  Action: Chairs will propose a mechanism to manage the Queue on the conference calls.

9.2      Issue 9   Destination to declare delivery QoS policies

http://lists.oasis-open.org/archives/ws-rx/200506/msg00046.html

 

No time to discuss

9.3      Issue  8> Granularity (per operation vs. per portType) of delivery QoS policies

http://lists.oasis-open.org/archives/ws-rx/200506/msg00053.html

 

No time to discuss

9.4      Issue 10> Single sequence to span multiple ports

http://lists.oasis-open.org/archives/ws-rx/200506/msg00059.html

 

No time to discuss

10   Any other business.

 

Meeting adjourned at 2:30 pacific time.