Prelim Minutes WSRM TC Conference Call –
Feb
03, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday Jan 27 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
0
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call
1 Roll Call
2 Minutes Discussion
2.1 Appointment of Minute Taker
2.2 Approval of previous meeting minutes –
3 Discussion of New Orleans Meeting and
Conference papers
4 Discussion of Action Items - http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5090/Action%20Item%20List%20from%20Jan%20Face%20To%20Face%20Meeting.htm
5 Discussions of Issues
Agenda approved
1
Roll
Call
Attendance:
|
First
Name
|
Last
Name
|
Role
|
Company
|
Voting
Level
|
|
Joseph
|
Chiusano
|
Member
|
Booz Allen Hamilton
|
1
|
|
Chris
|
Hipson
|
Prosp Member
|
BTplc
|
|
|
Peter
|
Furniss
|
Member
|
Choreology
Ltd
|
1
|
|
Jeff
|
Turpin
|
Member
|
Cyclone
Commerce
|
1
|
|
J
|
Durand
|
Member
|
Fujitsu
|
1
|
|
Kazunori
|
Iwasa
|
Secretary
|
Fujitsu
|
1
|
|
Tom
|
Rutt
|
TC
Chair
|
Fujitsu
|
1
|
|
Robert
|
Freund
|
Member
|
Hitachi
|
1
|
|
Eisaku
|
Nishiyama
|
Member
|
Hitachi
|
1
|
|
Nobuyuki
|
Yamamoto
|
Member
|
Hitachi
|
1
|
|
John
|
Fuller
|
Observer
|
Individual
|
|
|
Junichi
|
Tatemura
|
Member
|
NEC
Corporation
|
1
|
|
Alan
|
Weissberger
|
Member
|
NEC
Corporation
|
1
|
|
Sunil
|
Kunisetty
|
Secretary
|
Oracle
|
1
|
|
jeff
|
mischkinsky
|
Member
|
Oracle
|
1
|
|
marc
|
goodner
|
Secretary
|
SAP
|
1
|
|
Pete
|
Wenzel
|
Member
|
SeeBeyond
|
1
|
|
Doug
|
Bunting
|
Secretary
|
Sun
Microsystems
|
1
|
|
Tony
|
Graham
|
Member
|
Sun
Microsystems
|
1
|
Meeting was quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
Doug will record issue resolutions.
2.1 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5223/MinutesWSRMTC-012704.htm
Jacques moved to accept the Jan 27 minutes. Bob Freund seconded.
No opposition, f2f minutes approved.
3
Discussion of New Orleans Meeting and Conference
Tom Rutt received the
following mail from Oasis Staff:
Hello Chairs,
This is the preliminary schedule that we have
for TC meetings in New
Orleans. As you can imagine, we need to guarantee a
quantity of sleeping
rooms in order to get
the meeting room space at no charge, so it's important
that I get a final
commitment. Please confirm the number of TC members that
have booked their rooms
and please confirm the meeting times for your TC. I
can not confirm meeting
rooms until reservations are made. Also, please let
me know if you need 1/2
day instead of full day, plan to meet from
8:00am-12:00pm or 1:00-5:00pm. Thank you for your prompt
reply.
Regards,
Dee
|
|
25 April
Sunday
|
26 April
Monday
|
27 April
Tuesday
|
28 April
Wednesday
|
29 April
Thursday
|
Friday
|
|
Room
|
|
|
|
|
|
|
|
Small
Room 1--Audubon (holds 18)
|
|
|
|
OASIS
Board (10)
|
OASIS
Board (10)
|
|
|
Large
Room 2--Balcony I (holds 30)
|
|
|
|
WSRM
TC (10)
|
WSRM
TC (10)
|
|
|
Large
Room 3 Balcony L(holds 30)
|
|
|
|
Electronic
Court Filing TC (13)
|
Electronic
Court Filing TC (13), Integrated Justice Legal XML (30)
|
|
Large
Room 4--Balcony M (holds 30)
|
|
|
|
Emergency
Management TC (15) 8-12PM;
ebXML Registry TC 1:00-5:00PM
(6)
|
WS-CAF
TC (15-20)
|
|
|
Small
Room 5--Beauregard (holds 18)
|
|
|
|
XDI
TC
|
ebXML Registry TC (6)
|
|
|
Large
Room 6--Balcony N(holds 30)
|
|
|
|
WS-CAFTC 8:00-12:00 (15); ebXML
CPPA 1:00-5:00PM
|
CAM TC
|
|
|
Small
Room 7--Jackson (holds 18)
|
|
|
|
ebXML Messaging TC (10-12)
|
ebXML Messaging TC (10-12)
|
|
|
|
|
|
|
|
|
|
|
Waiting
List; LI-XML, WSDM
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Last
Updated 2/03/04
|
|
The eb-xml group did
not make a decision. They may want to
share meeting space.
Doug asked if there are other TCs to have a discussion with.
Doug suggested a short joint meeting with ebXml message group.
Up to ˝ day would be ok.
Pete stated that the best approach for WS
security would be through a request for review.
Tom Will contact chair of ebXML
messageing group.
Perhaps a ˝ day joint meeting.
Dee’s
messaged stated they expanded the block of reservations.
Marriott New Orleans.
Conference is Monday and Tuesday and wed and thurs are TC meeting.
April 26 is the Monday.
Need to discuss finalization of panel.
Jacques will send a proposal out to the entire
list for a panel discussion.
One panel on implementation of
WS-R. This would comprise WS-R TC
members. This remains pending.
Another panel idea suggested was on
compatibility with other complimentary specs.
How does WS-R fit in ecosystems of other specs. People outside our committee would be
interested in this.
Jacques has sent out another idea, overlapping
with implementation panel idea. “Value and limits of reliability in messaging”. Affect of network conditions. What are deployment constraints?
Now have three panel ideas, each 60 minutes,
with panelists chosen.
Name and/or roles for panelists need to be put
on the proposal by the Feb 9. Q & A vs short
presentations.
Jacques will broadcast this panel submission to
the list.
Jacques, we may want to propose additional panelist
beyond our members.
Other two panels: no volunteers.
Peter Furnis, Chorealogy might submit a paper to the conference. Relations to transactions. This might fit in as part of the panel.
They may be doing a paper on transactions. They might be interested in contributing to
this discussion.
Jacques will send out today. Jacques volunteered to make the final
proposal coordinator.
Sunil sent in a paper request.
One panel, Jacques to
coordinate.
4
Discussion of Action Item Status from Jan F2F
meeting
Action Item List Status - from Jan Face To Face
Meeting
1.
ACTION: Need to ensure faults in general being Cleaned up Sunil will try to
get a proposal to clean up fault text before the end of the F2f.. - DONE
2.
Action: Iwasa to apply changes for reo 44, then we will change status after done – done 3.1.1.
3.
Action: Iwasa is to produce a
change barred version of all the changes made from the 1-06 document. Use compare documents
under Edit to do it. - done
4.
ACTION: Sunil took action to come up with additions to the
model text for section 2.1 by Friday. – Done Suni
updated section 2 for polling
5.
ACTION: Jacques will make a proposal to fix these group
semantic concerns. Done, sent proposed updated wording to Iwasa,
which he has consolidated in last spec draft. See section 2.2 ("Groups of
messages and message identity").
6.
ACTION: Iwasa needs to remove the
sentence on the description of invalidExipiryTime
stating it is sent when the message expires. – done at 4
7.
ACTION: Iwasa has to factor in the
new syntax for the message Id schema in section 3.3. The sections need to be rearranged since some
items have been changed from elements to attributes., and some of the names
have changed - done
8.
ACTION: Sunil will provide text to include in the
specification for what is not covered by existing protocol for request/response
support. – done, see AI 9
9.
ACTION: Sunil will put a statement in a note regarding reply pattern
for one-way wsdl operations, to add to the operation/replypattern table. Done – text needs to be incorporated by
Iwasa.
Last para in 2.9 needs
to be recast as footnote on Supported entries in the request resonse row.
10. ACTION:
Iwasa will change MAY OPTIONAL for parameters to use
cardinality instead, for the entire document. – open
11. ACTION: Sunil will provide a
complete spec of the wsdl extension feature before we
decided on the resolution. Action Item closed, will discuss Issue later.
Done Sunil sent in
updated proposal to list To discuss as part of
resolution to issue 49.
Sunil has recast his
text in the mail.
WS-Capability Text from
Jacques, not yet put in the spec. To be
incorporated.
12. ACTION; Sunil will incorporate
the processing faults into his fault proposal for review on Friday morning. –
done see AI 14
13. ACTION: Iwasa
to change, in the first sentence of definition of guranteed
delivery to: “A message submitted to the sending rmp
with guaranteed delivery requested, will either be delivered by the receiving rmp, or the sending rmp will
notify the submitter of failure. “ – done section 2.3
14. ACTION: Sunil will provide a
new section 4, - done
15. Action: Iwasa
to add sentence: This element has cardinality zero or 1 in the rm-request message. – done in 3.3
16. ACTION:
Iwasa to add explanation for the table rows in
Section 3: e.g., for cardinality: “cardinality is a constraint on the number of
instances of an item type which may be present in an enclosing item.” - Done
17. Action: Iwasa
will finish updating section 3 to fully reflect the syntax changes for message
references. - done
18. Action: Sunil will update
the schema. – done and put in latest spec
19. ACTION :Sunil will come up with text to resolve this issue
on clarification of Poll semantics.. – done,.
20. ACTION:
Iwasa will add sub-section to section 3 for Fault
element. – Sunil and Jacques will help Iwasa Done in 3.5, but
this is only for soap 1.1. Needs some
refinement. Leave open
21. ACTION: Sunil will update to
have the soap 1.2 mapping of ws-reliability will not
use the rm:fault element,
but instead will use the soap 1.2 Subcode element.
Done
22. ACTION:
Iwasa will put soap 1.2 statement in the new section
in 3 on rm:fault element. –
still open
23. ACTION: Sunil will
incorporate amended fault proposal into the Schema and into the new text for
section 4. Done see AI 14
24. ACTION: Iwasa
will update section 3 to accommodate the new fault proposal – Same as Action
Item 20. – Close as duplicate
25. ACTION: Sunil add text that
a response to a poll may not coexist with a rm:request header.
Done see AI 19
26. ACTION: Iwasa
make the changes requested by Jacques for section 2 lead in. - done
27. ACTION: Jacques will add
clarification of sender/receiver synch of termination criteria for his homework on
clarifying group termination. Done, provided to Iwasa
as an updated draft, where the Group termination section has been significantly
reworded.
28. ACTION:
Iwasa will start working on new examples. – still open. Sunil
will send the roughed out schema examples.
Tom Will help send the examples to Iwasa. Still Open
Sunil will send out new schema at the end of this meeting. Examples in section 2 and 3 are done. Some examples still need to be added for
section 5. Partially open
29.
Action: Editors will produce up to date issues list by the next
meeting. done
The action items were reflected.
New issues list posted by Mark G as
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5273/wsrm-issues-2004-02-03.html
Iwasa has reflected
the agreements to date.
What about another draft.
Some editorial things.
The optionality was complete.
5
Discussion
of Issues
5.1 Issue
49 WSDL Annotation
Non normative
example of WS reliability capabilities text to Iwasa.
This issue can be considered
accepted.
Doug: if at this meeting
we decide to accept sunil’s text.
Doug: I am unclear about
the point of this. If it is a non normative
example, I do not understand how it improves interoperability.
Doug, having not seen the
detailed words, I am not clear how the capabilities is cast.
If it is listed as things
that people could agree to: I do not see the need.
Jacques, the concept of
capabilities is part of the entire understanding of WS-Reliability.
The intent on the lines
on capability was to give more structure to what sunil
was proposing in the annex. It helps to
understand what sunil does.
Sunil, the intention is
to have it be useful. Do not want it to
be normative.
Doug, my concern is
unnecessary complication of this specification.
This orthogonal work is going to be another point people will get
tripped up reading it.
Normative text:
exchanges will occur in context of agreements, work is
ongoing in a number of forums to standardize ways to attain agreement.
Alan: I agree with
Doug, to avoid confusing the user.
Jeff M: how about use
the WSDL 2 proposal for Features. At the
W3C there was proposal to enhance the proposal.
Feature and properties is progressing.
Jacques: one way to get
this addition of wsdl is to make it normative. The notion of capability might we several
ways, if in WSDL this is how it should be done.
Need way to specify
capabilities.
Jacques, send text to
list as a whole. He lumped
it to
If we decide the
Peter: Assigning a name
space makes it unique.
Jeff: Putting the
schema in the OASIS namespace does make it normative.
Peter
: if it we think it works, we could put it on.
Leave it open.
Discuss this on the
list.
5.2 Ack and Fault Response Contents
Sunil
sent email:
I
like to suggest that we add an attribute by name messageType
to the
response Header
element to easily distinguish a RM-Fault message with
an RM-Ack. Message. Currently we need to check for the existence
of
the Fault Header (for
SOAP 1.1_ to distinguish an Ack. To
a Fault.
This is some what tedious and instead having a
simple attribute with the type
of the message will
make it simpler and less error prone.
This attribute can have any one of the
following 2 values: Acknowledgment or Fault.
We have 2 ways to go wrt
optionality:
1) Make it mandatory and require that every
message has the type mentioned.
2) Make it optional and default to
Acknowledgment.
I prefer Option (2)
Issue Editors,
Could you please add this a new issue?.
Sunil
Rel-xyz is the text for the new issue.
We
will add new issue.
Put
pointer to mail before sending out.
Rel 114 for
this.
Iwasa was trying to add examples. In his example the fault did
not have the response element.
The
fault alone does not have the refToMessage pointer.
Could element messageType, with values ack or fault.
Make
it mandatory attribute or default.
Doug:
I have been confused by flurry of emails.
We got rid of message type
Because
we had a fair number of use cases with requests and responses combined in the
same message.
Not
currently clear what the spec implies.
Cannot enforce that errors may come back without reliable message
header.
Doug
needs to re-ask question.
Text
stated that fault is for one message only.
If
ref to message
This
is an optimization to put ResponseType indication in
the response header.
Doug
is concerned that this is an early optimization and complicates things
necessarily.
Sunil:
without this it complicates further.
Leave
open discuss on list.
Meeting
does Agree that you have to send response header with
fault. The remaining question is whether
the response header needs a response type attribute.
5.3
Rel 106 Group
termination after delivery
Description:
Should
a reciever only update group termination value for
messages which are delivered?
Tom
Rutt took action item to initiate discussion on email
list to resolve this issue.
5.4
Rel 108 Clarify
semantics of polling
Description:
Clarify
that reply to a poll only includes succesfully
delivered messages.
Several
members stated that this has already been resolved with clarifications in the
current editor’s draft. In particular we
added a clarification that a Poll may be done for messages which were send by other reply patterns.
The
meeting ran out of time to verify this.
We
can close this issue next meeting if we verify that the clarifications for
polling semantics are indeed in the most recent editor’s draft.
Meeting
closed at 7:00 Eastern Time.