Prelim Minutes WSRM TC
Conference Call – August 26, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday August 26, 2003, from 5:30 to 7:30 PM Eastern Daylight Time
(UTC - 4)
The call in details wer 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 – August 26, 2003
The next meeting of the WSRM TC will take place by teleconference
Tuesday August 26, 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 is as follows:
1 Roll Call
2 Minutes Discussion
2.1 Appointment of Minute Taker
2.2 Approval of previous meeting minutes
8/12/2003 Teleconference minutes:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3229/MinutesWSRMTC-812.htm
3 Discussion of Issues:
<check for up to date issues list >
4 Discussion of Editor’s Draft Requirements Document
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3194/Web_Service_Reliability_Requirements_v0_8.pdf
5. Discussion of agenda and attendance for Boston F2F meeting
Jacques explained they want to Add discussion of Plan for Demo, on Thurs on 1:oo PM to 2:00 PM Thurs Sept 4 th. They can forward details on demo to those interested.
Proof of concept for ws rm v 1.0, is what they based demo on.
Participation NEC, Hitachi, Oracle, Fujitsu are committed for now.
Jacques described that they will pair off to demonstrate features of protocol. This is a demonstration of feasibility, using out version 1.0 features.
Making a demo early is to provide feedback to specification.
Alan asked if participants have a future trade show in mind for a more complete demo.
Jacques agreed to be a focal point for other members who are interested in participating in future demos.
Have a mailing list wsr@fsw.fujitsu.com.
Alan stated the demo is a good idea.
Do are working with the host MITRE. They will fill in details with Doc on this.
Agreed to put hour on agenda for the demo.
Sunil asked about if we can make a formal sub TC for this effort.
Doug B stated the procedures for subteams vary by committee, and the way to decide is by a vote to determine the process for any particular TC. UBL subteams are very different from those in VT TC.
There are logistics involved from Kavi mechanics. Doug would recommend looking at process on OASIS web site.
Tom Rutt suggested to put feasibility demo subcommittee discussion on the agenda for Friday Morning.
Doug stated the for agenda for next week’s meeting. The items are separate in the agenda. One if we want to have multiple formal subteams, followed by a specific one regarding a subteam for proof of concept.
Iwasa posted a new editor’s draft to the web site.
Iwasa stated the document is updated with resolutions for some issues. The issues resolved in the document are 18 (combined message type), 21 (remove from/to), 54 (remove service element), 46 (change location of fault element), 53 ( remove message ID)
Examples are not changed. Need to be updated. Synch / asynch needs to be changed.
Iwasa will try to update remaining issues. He will post the document by Friday evening Japan time. The document has a list of solved issues to document.
1
Roll Call
|
First Name
|
Last Name
|
Email
|
Company
|
Voting Level
|
|
Jeff
|
Turpin
|
jturpin@cyclonecommerce.com
|
Cyclone Commerce
|
1
|
|
J
|
Durand
|
jdurand@fsw.fujitsu.com
|
Fujitsu
|
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Fujitsu
|
1
|
|
Tom
|
Rutt
|
tom@coastin.com
|
Fujitsu
|
1
|
|
Jishnu
|
Mukerji
|
jishnu@hp.com
|
Hewlett-Packard
|
1
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Hitachi
|
1
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Hitachi
|
1
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Hitachi
|
1
|
|
Ben
|
Bloch
|
ben_b54@hotmail.com
|
Individual
|
1
|
|
Mark
|
Hansen
|
khookguy@yahoo.com
|
Individual
|
1
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
NEC Corporation
|
1
|
|
Alan
|
Weissberger
|
ajwdct@technologist.com
|
NEC Corporation
|
1
|
|
Magdolna
|
Gerendai
|
magdolna.gerendai@nokia.com
|
Nokia
|
1
|
|
Szabolcs
|
Payrits
|
Szabolcs.Payrits@nokia.com
|
Nokia
|
1
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Oracle
|
1
|
|
jeff
|
mischkinsky
|
jeff.mischkinsky@oracle.com
|
Oracle
|
1
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
SAP
|
1
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Sun Microsystems
|
1
|
|
Chi-Yuen
|
Ng
|
cyng@csis.hku.hk
|
U of Hong Kong
|
1
|
|
Patrick
|
Yee
|
kcyee@cecid.hku.hk
|
U of Hong Kong
|
1
|
Meeting is quorate.
2
Minutes Discussion
2.1 Appointment
of Minute Taker
Tom Rutt
will take minutes.
Doug agreed to take
issue resolutions. He has not yet posted
a new item on the web site.
2.2 Approval
of previous meeting minutes
8/12/2003 Teleconference minutes:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3229/MinutesWSRMTC-812.htm
Bob Freund moved to accept minutes, Iwasa seconded.
No opposition, minutes approved.
3
Discussion of Issues:
3.1 Rel 56
This was deferred from
last meeting.
Doug summarized current
status:
Alan sent out detailed
email at the end of July, that has seen little discussion on the email
list. Iwasa
has referenced it in a couple of places, in his recent emails.
The issue stated it is
an action to read Alan’s email.
Parameters
to carry in protocol elements.
Other parameters
determined outside the protocol.
Alan mail:
All
Here
is the original mail, which I
provide in-line comments IN CAPS/ UPPER CASE
alan
-----
Original Message -----
From:
"Alan Weissberger" <ajwdct@technologist.com>
Date:
Mon,
14 Jul 2003 15:43:46 -0500
To:
wsrm@lists.oasis-open.org
Subject:
[wsrm] Thoughts on WS-RM configuration parameters
>>
All
>>
>>
Even though we agree that SLA/ configuration management protocol and
mechanisms are outside scope of WS-RM TC, I believe we should atleast list the parameters in an Appendix of our spec,
along with suggested default values (we might even chose to recommend ranges of
values for the parameters)
>>
>>
Here is a preliminary list of Configuration parameters that the WS-RM sender
and receiver should agree on prior to SOAP message exchange:
1. Maximum message lifetime/duration (determines upper bound on message
expiration time)
AW: MANDATORY PARAMETER TO PREVENT INDEFINITE/
NEVER ENDING MESSAGE EXPIRATION
2. Maximum message group (or message sequence)
lifetime
AW: MANDATORY PARAMETER TO PREVENT INDEFINITE/
NEVER ENDING MESSAGE SEQUENCE EXPIRATION
3. Resend interval (SEE REL 47)
AW: MANDATORY PARAMETER, NEGOTIATED BETWEEN
SENDER AND RECEIVER, TO PREVENT TOO LONG OR TOO SHORT RE-TRANSMISSIONS (SEE NOTE BELOW)
>> - minimum interval: the minimum duration the
sender should wait after sending a message
>> and before
resending the message. This is AKA Retransmission timer value
>> - Note: we may LATER introduce algorithms to
control resend interval (e.g., exponential backoff).
4. Retransmission count (SEE REL 47)
THIS
IS the number of unack'd re-transmsissions
the sender makes before declaring an unrecoverable problem WITH THE WS-RM
CONNECTION
AW: LOCAL PARAMETER THAT MAY NOT HAVE TO BE
AGREED UPON BY BOTH SENDER AND RECEIVER
5. Capability exchange: Parameters TBD.
For
example: the types of MEPs supported, WS-RM spec
options supported, additional transport bindings supported (besides HTTP),
message storage persistance classes/ capabilities,
recovery actions to be taken on failure and/or failure recovery (power outage,
no-ack count expired, crash tolerance, etc).
AW:
THIS IS AN OPTIONAL CAPABILITY, DEPENDENT ON A CONFIGURATION/ PARAMETER NEGOTIATION
MESSAGE EXCHANGE. PERHAPS WE CAN LIST
THE PARAMETERS TBD THAT ARE IMPORTANT TO SENDER AND/
OR RECEIVER.
Alan Weissberger
NEC Labs America
1 408 863 6042
Alan
Weissberger
Iwasa
has proposal:
Rel56: Describe all configuration information in the spec
Proposed Resolution:
Create a configuration parameter list to be included
as appendix in the spec. And include Retry count and time
duration in the list. We can add any other parameters
later if we found.
This is in general agreement
with the proposal from Alan.
The capabilities
exchange is the one which needs discussion.
Rel 47 is the fallout if we decide to keep
message retry duration in protocol.
Iwasa
stated that time duration was not included in header element.
Doug stated that these
issues are confused.
Jacques stated he might
have examples for parameters of the item 5 in Alan’s mail.
How far in the past do
we go to cover duplicate check is another example. He can propose something on the list.
Doug proposed separating
into two lists. One as parameters for
sending message
And
the other for parameters for receiving messages.
He would prefer to see
the parameters separated into sending and receiving.
Doug stated we need to
describe the affect of each of these parameters on senders and receivers.
Jacques stated he would
work on updating the list, including what the sender and receiver would do with
the list.
Leave rel 56 open for now.
3.2 Rel 47 retry count and retry interval
The group agreed that rel 47 is a separate issue from rel
56.
Retry Interval is what
47 is talking about.
Iwasa
stated that his resolution of 47 entails having the retry count and retry
interval as config parametes,
not carried in wsrm protocol.
Doug stated that the
original questions was whether these parms could be
described in spec, and also included in schema.
Rel
47 is on whether retry count and retry interval should be part of protocol.
One proposal is that
those not be included in protocol. This
is an answer, however we left the meeting on 29th
without that resolution.
Retry count has no
fundamental bearing on operation of protocol, but is a policy which an
implementation may wish to impose. Can
sender live with knowledge of either of these two parameters. Agree that protocol will work if sender does
not know the value of retry count or retry interval.
Does
not matter how sender choses this policy.
General Agree it does
not matter if receiver knows these values.
Proposed motion text:
Doug moved Jeff Turpin
Seconded. Close Issue Rel 47 with text:
Include retry count and
retry interval in list of parameters described by resolution to Rel 56. These
parameters will not appear in the protocol.
No opposition, rel 47 issue closed with resolution.
3.3 Rel 15
Iwasa
asked how he should update the spec with this resolution.
Doug stated that this
is a requirements issue. The implication
is that this is a completeness requirement.
Talk about proposals to
spec to meet requirement.
Status query is an
example.
Before we are done we
need all the faults.
Review draft spec at
f2f to identify which requirements have not been realized in the spec.
Doug stated to move
something from completed to closed, we need to accept updated doc, or accept
edits have been done.
It would be worthwile to schedule f2f time to do this for both
requirements doc and spec doc.
Doug suggested that we
could duplicate every accepted requirements issue as a
separate technical changes to the spec.
Two possibilities:
- Turn list of requirements into a list of
issues for spec
- Duplicate closed requirements issues
Could also edit the
requirements with annotations suggesting the requirement has been reflected.
Doug agreed to add a new set spec issues to track requirements being met by
spec.
3.4 Rel 16
Agreed to simplified statement:
“
When a sender sends
multiple messages with Guranteed message ordering,
the sender is REQUIRED to include MessageOrder
element in each message.
all messages to be delivered in order MUST have same GroupID
and MUST have a sequence number as a value of SequenceNumber
element
in order for the message to be delivered to receiver's application.
When the sender
requests Guranteed message ordering for a message,
the sender MUST use Guaranteed message delivery and
duplicate elimination for that message as well.
In particular, the
sender MUST include both AckRequested
element and DuplicateElimination element, as well as
the MessageOrder element for Guranteed
message ordering.
“
After text included in
doc, Doug will move this issue to completed.
3.5 Rel 51 Message Piggybacking
Message on 12 August:
Bob Freund proposed:
Remove
message type element
Let
rm response element coexist with other elements.
Bob stated the
motivation is to reduce traffic for acknowledgements.
Tom asked if there will
be confusion regarding removal of message type element.
Iwasa
agreed that the proposal seems reasonable.
Magdolna
also agreed.
Doug stated he is not
sure the proposal will close the issue completely. Remember the issue resolution and be aware of
fallout later.
There could be protocol
implementations as well.
We need to be aware
that we are slightly changing semantics of other elements.
This is already a spec
issue.
Accept proposal for Rel 51 resolution.but leave spec
issue as not fully closed. The only
issues that are closed are those with closed no action.
Accept proposal, and
leave issue in state of waiting for full implementation.
Bob moved to accept his
proposal to :
remove
message type element.
Allow rm respons with any other
element.
Doug seconded.
No opposition motion
passes.
The issue cannot be
fully closed until the protocol text is fully updated.
New spec issues:
3.6 Rel 57 Ordering and missing message behaviour
This came out of
resolving rel 16.
Scott Werden posted the message.
Option a: send fault
back to sender abort all further ordering for group.
Option b: send fault back deliver succeed messages
before they timeout, continuing ordering.
Option c: other
Option a was expressed as a preference for Patrick Yee.
Doug suggested for c
silently dropping other messages.
We should have
discussion on this for email before resolution.
3.7 Namespace
ID
Joe C suggested to use OASIS URN.
Doug stated we have to
set some high level bits:
Use namespace id in
http scheme or oasis urn scheme.
Doug suggested that we
need to answer a small set of questions:
What schema namespace
ID to be in
Should first namespace
include protocol version
For multiple schema
docs for 1.1 and 1.2 do we have different namespaces.
Doug agreed to put
these questions in to the new issue to assist in the resolution.
4
Discussion of Editor’s Draft Requirements
Document
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3194/Web_Service_Reliability_Requirements_v0_8.pdf
Will be discussed at the meeting.
Remaining rel item for requirements document is item 56.
Put on agenda for Wed morning to approve the draft requirements doc.
5
Discussion of agenda and attendance for Boston F2F meeting
Tom agreed to make draft agenda by tomorrow. Will include items discussed in these minutes, including the demo on Thursday.
Agreed to have the f2f be in place of next call in two weeks.
Agreed to have next teleconf on the 16th of September, and onwards in two week cycles.
Go on into sept 30, October 14 and oct 29.
Timing for conf call at end of meeting two hours from 10:30 until 12:00 noon will be teleconf.
I will put out notice for this call. It will be the same number we have now.
It looks like we will be quorate.
Draft agenda on web site tomorrow. Comment on email change at meeting if we have to.
Jishnu moved to adjourn, Doug seconded.