Prelim Minutes OASIS WS-RX TC Weekly Conference Call
Date: Thursday, 28 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
|
First
Name
|
Last Name
|
Role
|
Company
|
|
Alexander
|
Leyfer
|
Voting
Member
|
Actional Corporation*
|
|
Charlton
|
Barreto
|
Voting
Member
|
Adobe
Systems*
|
|
Duane
|
Nickull
|
Voting
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
|
|
Rich
|
Salz
|
Voting
Member
|
Datapower Technology, Inc*
|
|
Andreas
|
Bjarlestam
|
Voting
Member
|
Ericsson*
|
|
Nilo
|
Mitra
|
Voting
Member
|
Ericsson*
|
|
Jacques
|
Durand
|
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
|
Member
|
IBM*
|
|
Peter
|
Niblett
|
Member
|
IBM*
|
|
Rebecca
|
Bergersen
|
Voting
Member
|
IONA Technologies*
|
|
Paul
|
Cotton
|
Voting
Member
|
Microsoft
Corporation*
|
|
Colleen
|
Evans
|
Voting
Member
|
Microsoft
Corporation*
|
|
Jonathan
|
Marsh
|
Voting
Member
|
Microsoft
Corporation*
|
|
Jorgen
|
Thelin
|
Voting
Member
|
Microsoft
Corporation*
|
|
Asir
|
Vedamuthu
|
Voting
Member
|
Microsoft
Corporation*
|
|
Chouthri
|
Palanisamy
|
Voting
Member
|
NEC
Corporation*
|
|
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*
|
|
Heidi
|
Buelow
|
Voting
Member
|
Rogue
Wave Software*
|
|
Michael
|
Bechauf
|
Voting
Member
|
SAP AG*
|
|
Sanjay
|
Patil
|
TC Chair
|
SAP AG*
|
|
Claus
|
von Riegen
|
Voting
Member
|
SAP AG*
|
|
Umit
|
Yalcinalp
|
Voting
Member
|
SAP AG*
|
|
Blake
|
Dournaee
|
Prospective
Member
|
Sarvega
|
|
Giovanni
|
Boschi
|
Applicant
|
Sonic
Software
|
|
Dave
|
Chappell
|
Voting
Member
|
Sonic
Software
|
|
Vikas
|
Deolaliker
|
Voting
Member
|
Sonoa Systems, Inc.*
|
|
Doug
|
Bunting
|
Voting
Member
|
Sun
Microsystems*
|
|
Dan
|
Leshchiner
|
Voting
Member
|
Tibco Software Inc.*
|
|
Shivajee
|
Samdarshi
|
Voting
Member
|
Tibco Software Inc.*
|
|
Vadim
|
Furman
|
Voting
Member
|
webMethods, Inc.*
|
Meeting
is quorate.
.
2
Review and Approval of Agenda
Agenda:
1) Roll Call
2) Review and approval of the
agenda
3) Approval of the Jul 21st meeting
minutes
http://www.oasis-open.org/committees/download.php/13746/MinutesWSRX072105-b.htm
4) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
5) New issues since last conf-call
http://lists.oasis-open.org/archives/ws-rx/200507/msg00259.html
6) Issue Discussion: Assign owner
and discuss resolution
a> Issue i014: Document
Names
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i014
b> Issue i013: Max message number in policy
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i013
c> Issue i018: Is an implementation
supporting a smaller max message number valid?
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i018
d> Issue i019: Sequence termination on Fault
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i019
e> Review issues i015, i016 and i017
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml
7) Any other business
Marc G wanted to add meetings in august as part of any other
business.
Paul F: leave of absence requests also to be discussed in ahy other business.
3
Approval of the Jul 21 meeting minutes
http://www.oasis-open.org/committees/download.php/13746/MinutesWSRX072105-b.htm
Tom
Rutt moved, Anish seconded to approve the 7/21 minutes.
§
No Opposition Minutes approved.
4
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#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:
Open: Jamie has not yet posted the changes
Assigned:
2005-07-06
Due:
2005-07-08
#0007:
Sanjay to set up editing team Subcommittee or mailing list
Owner:
Sanjay Patil
Status:
Closed
Assigned:
2005-07-08
Due:
2005-07-14
#0011:
Chairs should start a KAVI ballot asking members if they will attend the Face
to Face meeting, either in person or by teleconference
Owner:
Paul Fremantle
Status:
Closed – members should cast their vote soon.
Assigned:
2005-07-17
Due:
---
#0012:
Chair took an action item to get a ruling from Jamie on CVS repository usage.
Owner:
Paul Fremantle
Status:
Open – waiting for response
Assigned:
2005-07-17
Due:
---
#0013:
Chairs will propose a mechanism to manage the Queue on the conference calls.
Owner:
Sanjay Patil
Status:
Open
Assigned:
2005-07-17
Due:
---
#0014:
Marc G should review Jacques suggestion for new issue status, and report to TC
by next week call
Owner:
Marc Goodner
Status:
Closed Marc G stated it would not help
his work flow. Do not need to add new status for submitted issues.
Assigned:
2005-07-27
Due:
2005-07-28
#0015:
Forumulate use case/requirement for issue i009
(Declaration of QoS policies)
Owner:
Christopher Ferris
Status:
Open
Assigned:
2005-07-27
Due:
---
5
New issues since last conf-call
Marc
G email on this topic
http://lists.oasis-open.org/archives/ws-rx/200507/msg00259.html
proposed-01
Semantics of "At most once" Delivery
assurance
all - design -
unassigned
Description
The
semantics of the "at most once" delivery assurance are not clear.
One
interpretation is that at most once implies that the sender is not required to
retransmit mesages which are not acked.
Related
to i009
Justification
It
is important to clarify whether the sender must retransmit unacknowledged
messages when the "at most once" delivery assurance is in use.
Origin
Tom
Rutt
Proposal
12005-07-21
Clarify
the semantics. There are at least three possible semantics associated with
"at most once"
1. At most once
means that the sender will never retransmit a message, regardless of whether it
is acknolweged by the destination.
2. The sender may retransmis
messages, but is not required to to so, however the
destination will not deliver duplicates
3. The sender must retransmit messages, however the destination may drop messages in times
of resource saturation, but will never deliver a duplicate.
Agreed to add proposed-01 to issues list – owner Tom Rutt.
proposed-02
An RM Policy applies two-way
policy - design -
unassigned
Description
In
WS-RM Policy, and per WS-PolicyAttachment, RM Policy
assertions may be attached to ports. E.g, details of
parameters for the resending mechanism. It is implied by doing so, that both
inbound and outbound messages are subject to this policy. This assumes that
there is a strong case for in and out messages always using the same Delivery
assurance. In effect this is saying that an RM Policy applies to two
Destinations: the destination of the inbound messages,
and the destination of the outbound messages (meaning for example to both a WS
endpoint and its clients).
Justification
Evidence
for such an aggregation of quality of service is unclear: On the contrary, both
(a) differences in technical capabilities between Source and Destination, and
(b) differences in business and QoS requirements,
suggest that a policy (delivery assurance) defined for messages going one
direction, may not be appropriate for messages going the other way.
Origin
Jacques
Durand
Proposal
12005-07-21
Even
if the scope of an RM Policy remains at port level there could be an additional
scoping attribute stating inbound vs outbound. Yet a
cleaner way seems to make use of finer granularity in the attachment (as
allowed by WS-PolicyAttachment).
Deferred
discussion until Jacques is present
Jacques
stated that the policy attached to an input message should not always be the
same as that applied to the response message. They apply to different endpoints.
Ashok: would it be ok if the policy was attached to the
message rather than port type.
Jacques:
that would one resolution to this issue.
Marc
G: is this the same as Issue i08 on policy granularity.
Tom
Rutt: that is more about operation level at the
destination.
Jacques:
they might be seen as related, and solutions for one could apply to the
other. I would prefer to keep them
separate.
Agreed to add proposed-02 to issues list, with Jacques as owner.
proposed-03
RM Policy Assertion Model's Base
Retransmission Interval Clarification Needed
policy - design -
unassigned
Description
The
RM policy assertion model defines InactivityTimeout
and BaseRetransmissionInterval. The text in the
specification WS-RM Policy (Page 5) implies that these two parameters are
essentially serving the same purpose i.e. to trigger a retransmit based on a
timeout value. If this is the intention, the spec needs to clarify the pecking
order for an implementation i.e. what if timeout occurs before base
retransmission interval has expired.
Justification
There
is no obvious case mentioned in the spec that requires two timers for
retransmission upon timeout.
Origin
Vikas Deolaliker
Proposal
12005-07-22
Merge
the two into one timer called Retransmission Timeout.
Anish: From my understanding there is some misunderstanding
about what the two assertions are for. Chris
F email states they are for different purposes and cannot be combined.
Tom:
The inactivity timout is for closing the sequence, however the BaseRetransmission
interval is a smaller value for the time between individual retransmissions of
same message id.
Agreed to add propose-03 to issues list, with Vikas
as owner.
proposed-04
Robust recovery from low-resource conditions
core - design -
unassigned
Description
In
situations where the RMD is running low on resources, it may want to provide
hints to the RMS of its situation with the expectation that the RMS pauses or
slows down the (re)transmittal of messages and avoid further straining of RMD
resources until recovery. The current solution of statically associating an ExponentialBackoff policy assertion may not be timely and
sufficient in all the cases and a more dynamic solution for throttling the
message flow may be needed.
Justification
In
a low-resource situation, it is likely that the RMD would discard any incoming
messages and stop sending any Acks. Since the current
protocol design does not provide for the RMS to become cognizant of the
situation on the RMD side, RMS may simply keep on (re)transmitting messages
resulting into further resource utilization (network bandwidth, processing
power on both ends, etc.) and possibly making the situation worse. It seems
that a better option may be for the RMD to push back on the RMS in the event of
low-resource like situations and request the RMS for pausing or slowing down
any (re)transmissions.
Origin
Sanjay
Patil
Proposal
12005-07-26
RM
Protocol to support RMD pushing back on the RMS for slowing down or stopping
(re)transmission of messages.
Agreed
to add proposed-04 to issues list, Marc G agreed to be owner..
Anish: I think that this flow control scenario is quite
valid. However, I would like to raise
caution that the protocol submission has not addressed flow control, and there
are more issues that this.
Marc
G: there may be scope issues with the charter itself.
The
owner drives the issue, by presenting during calls, and should propose
solutions and leads email discussions.
Ashok: I had send out mail about possible issue, on WS-RX
policies not being reflected in messages.
Sanjay:
I request that you submit using the formal template.
6
Issue Discussion: Assign owner and discuss
resolution
6.1
c> Issue i018: Is an implementation
supporting a smaller max message number valid?
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i018
Doug B: the email to date indicates that people are
comfortable with a designed in limitation for an implementation that is less
than the max unsigned long for a sequence number. The spec should not attempt to define a max
for conformance. Testing would be that
the declared max is supported in an implementation. I am unsure how to fully close
this issue without opening the conformance clause rat hole.
Duane N: could we have a parking lot for conformance issues.
Doug B: close no action means that there is nothing in the
spec requiring an implementation to support the full length of unsigned long.
Doug B: Proposal:
The answer to the question is “yes”. Enforcement of a particular smaller number is
not currently disallowed, so we should close this issue with no action.
Anish: I though should go to draft
status, editor’s would not have to do anything.
Peter Niblet: Is the intention to
add an appendix for conformance clause, beyond the normative MUST clauses.
Sanjay: Marc G is going to start a group on how to gather
individual conformance issues.
Chris F: Is the substance whether an implementation may
support a max less than the schema max.
Doug B: the rationale to close with yes is that any lower
limit enforced in the spec will be impossible in some deployment
scenarios.
Chris F: your proposal is to leave as is, implying that it
is ok for a Java to support only the max of a long, rather than unsigned long.
Tom R: why would a clarification not be useful.
Doug B: the clarifications would be better to deal with in
the other two issues in this area.
Jeff M: what about the conformance issue.
Doug B: one of the other issues has a proposal to add a
policy statement on the max messageID value supported
by the implementation.. Conformance would be related to this policy
value.
Sanjay: the core of this issue is just whether a smaller
value of max is allowed.
Ø
Action: Marc G will form a team to discuss how
do deal with conformance related issues on the specification.
Sanjay: Why not put this clarification in the spec.
Doug B: a policy assertion allowing an implementation to
state it supports something less makes this very clear.
Jeff M: What if there is no policy assertion,
is the implementation still allowed to support smaller than schema max.
Paul F: this issue is prior to the policy issue. We should
record the answer that we support max values less than the schema max, then
move to issue 19. This will be clear in
the spec. However we should make the
answer to issue 18 known.
Chris F: It is more than just a policy issue. We can table this discussion for now, perhaps
with a straw poll on the answer, and then move on to resolving the other issues
in this area. The destination threshold
being exceeded can be less than the xs: schema max
for unsigned long. I suggest we move on,
and discuss the other issues in this area, then close them together.
Duane N: when we talk about this we have to distinguish the
sequence number being exhausted, versus the resources are exhausted. Large messages can cause overload in the
resources of the destination.
Doug B: I would like to take another stab at the proposal,
incorporating some of the discussion in a rewording:
Doug B new Proposal:
The answer to the question is yes. An implementation may support a smaller max
than the xs: schema definition for unsigned long.. No change is
necessary to the text as a result of this answer to the question. Any changes to text are likely to come from
the other issues. Table discussion of
text changes until we see resolution of other issues.
Chris F: we could just record the answer as yes, then close the issue with no text changes necessary.
Jeff M: we should not be reopening closed issues.
Chris F: I agree that we do now re-open issues,
we could open up new issues.
Sanjay: how can we stop from reopening old issues.
Chris F: To make progress the group should not reopen old
issues.
Jeff M: We need a very high bar to re-open issues. Adding clarifying text could be incorporated
through a new issue.
Paul Cotton: New compelling information raised at a future
meeting should allow an issue closed a prior meeting to be re-opened.
Paul F: people may try to add a new issue which, in effect,
reopens an older issue. However the committee
would have to agree to the new issue as being warranted. We need to get more progress on closing
issues.
Motion by Doug B, Seconded by Chris F: “The answer to the
question asked in the title is "yes"; an implementation supporting
less than 18 quintillion as the maximum message number is valid. With regard to the specification at this
time, no change seems necessary. Any
clarification necessary to make this lack of an implementation requirement
clear is likely to come from resolutions to i013: Max message number in policy
and / or Issue i019: Sequence termination on Fault.”
§
No objections, issue moves to closed with no action
necessary.
6.2
b> Issue i013: Max message number in policy
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i013
Current the message id rollover fault terminates the
sequence.
Deferred for lack of time
6.3
d> Issue i019: Sequence termination on Fault
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i019
It is unclear what the termination os
the sequence is. Does it allow
resumption of the sequence.
Deferred for lack of time
6.4
a> Issue i014: Document Names
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml#i014
Deferred for lack of time
6.5
e> Review issues i015, i016 and i017
http://www.oasis-open.org/committees/download.php/13758/ReliableMessagingIssues.xml
Deferred for lack of time.
7
Any other business
Sanjay:
Thurs 18 august, and 25 august both chairs will not be able to participate in a
tele-conf.
Paul
C: we could appoint pro-temp chairs in this situation.
Jacques:
I have no issue with spacing meetings in slow months, such as August. Giving how much work is needed, keeping some
meetings might work , but the chairs should consider
making up with longer meetings for subsequent meetings.
Paul
C: That is just reopening our discussions at the last fact to face. Skipping meetings seems to be a bad idea. We need as many meetings as possible.
Sanjay: We could post a ballot on just those two
meetings.
Paul
F: You are about to enter into a complex negotiation with a large number of
different people. If you go alternate weeks, they better not be on the wrong
days.
Chris
F: It is important to keep moving forward,
We can
rely on leave of absence to help with any quorum problems. I agree with Paul. C
Paul C moved to meet on the two days 18
august and 25 August, Seconded by Tom Rutt.
Bob F moved to limit debate,
§
No objection on motion to limit debate.
Meeting
ran out of time, Chair suggested a ballot on the meetings, with a separate
ballot for pro temp chairs.
§
Two ballots will be raised, one for each of the
dates.