Full Agenda WSRM TC Conference Call Mar 02, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday Feb 24 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
Conference call Dial-in number : Toll number (only): 1-512-225-3050 Participant code: 89772
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 Discussions of Issues
5 Discussion of
Editorial Comments
6 Discussion of Document Progression
??? approved
1
Roll
Call
Attendance:
Meeting ?? quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
??? will serve to record issue resolutions.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5702/MinutesWSRMTC022404.htm
xx moved to accept the Feb 24 minutes. yy seconded.
?? opposition, 2/24 minutes ??approved.
3
Discussion of New Orleans Meeting and Conference
Tom stated he told the OASIS staff that we
wanted to meet all day Wednesday, and Thursday morning for our F2F. This has been verified.
4
Discussion
of Issues
Issues which were already resolved:
Old resolve issues: Rel
105, 106
On 2/17 we resolved Rel
102
Last week we resolved issues Rel
108, 115, 114, 116,
4.1
Issue 49 WSDL Annotation
.
4.2
Rel
117 Soap fault for missing reliability features in request
I propose we close this by adding
the following to the paragraph on Soap Faults:
For a WSDL request/response
operation request, if the receiver does not want to invoke the service since a
required ws-reliabiliy feature is not requested, then
it MUST generate a soap server fault. In
this case, the fault detail SHOULD indicate that a required reliability feature
was not requested.
4.3
Rel
118 Clarification Issue on Service enforcement of agreement
4.4
Rel
119 Sunil new Issue on Callback for Poll Request
- New
Issue
From Sunil Kunisetty
<Sunil.Kunisetty@oracle.com> on 24 Feb 2004 00:50:10 -0000
New mail
from Sunil:
If we do accept this, here are the changes that we need to do.
1. Add an optional replyTo attribute to PollRequest
2. pg 6/line 177: Remove
the replyTo attribute for Poll pattern in Request (this may
contradict to what I said in the editorial comments...)
3. pg 7/line 212:Title of Example 3 would read "Acknowledgment Message
embedded in HTTP Request"
4. pg 7/line 213:HTTP Headers will have to change (should use POST)
5. pg 8/line 239:Title of Example 4 would read "Fault Message embedded in HTTP Request"
6. pg 8/line 240:HTTP Headers will have to change (should use POST)
7. pg 11/lines 334-339
should be reworded as follows:
We say that
Polling RM-Reply pattern is used if a second underlying request is issued to
the
receiver
of a previous message, in order to obtain a RM-Reply. The RM-Reply can be
either
contained
in the underlying response to this poll request or in a separate underlying
request
from
the receiver to the sender. This poling pattern is generally expected to be
used in
situations
where it is inappropriate for the sender of reliable messages to receive
underlying
protocol
requests (behind the firewall cases) or to avoid resending bulk messages often.
1. pg 15/Figure 3. The
3rd line should be titled "Underlying protocol Response/Request".
2. pg 28/section 4.3
1. Table 9: Add an
optional attribute call replyTo of type anyURI
2. We need to
mention that RM-Reply MUST be contained in the underlying response of the Poll
request if this attribute doesn't exist and should be sent in an underlying request to the endpoint
identified by this attribute if exists.
3. And finally the schema
has to reflect this by
adding an optional attribute to the PollRequest
element.
-Sunil
4.5
Soap 1
We
closed this issue, but where is the soap 1.2 compatible schema?
Mail
from Sunil:
I
was about to venture into the WS-RM schema for SOAP 1.2 and realized
that the only
difference would be the namespace for the SOAP Envelope
and the mustUnderstand attributes.
So having 2 different schemas/namespaces is
causing me some goose bumps.
I've to admit that I was the one who initially
suggested to have 2 different
schemas/namespaces
for SOAP 1.1 and SOAP 1.2. However, at that time
strict schema
validation is critical (ofcourse even now its
important) and there
are Header elements
such as Fault Header which is used only for SOAP 1.1.
And now that we have many occurrences such as
existence of groupMaxIdleDuration
and groupExpiryTime attributes and replyTo
attribute for Response and Poll
pattern which cannot
be validated with schema and only thru' specification, so
having both mustUnderstand attributes (one for soap11 and other for
soap12)
on HeaderBaseType doesn't look that bad either. We then have
to say in our
specification clearly
that one of these attributes MUST appear with a fixed
value '1'.
2 different schema will result in more
examples (we have 2 give atleast one
example with soap 1.2
envelope), more appendixes, more maintenance,
however, much
cleaner.
So essentially I don't know which is lesser of
the evils... I want to finalize this
before I come up with
SOAP 1.2 schema for WSRM.
Thoughts???
-Sunil
5
Discussion of Editorial
Comments.
Editorial Comments for Discussion
6
Timing of WS-Reliability progression
Timeline
proposed at F2F meeting.
- Feb
10 Tuesday
call, final editing instructions agreed.
- Feg 12 Document posted for TC internal review.
- Feb
24 TC review comments resolved, editing instructions produced.
- Feb 25 Frozen
document completed, TC review begins.
- March
2 CD 1 ballot closes
- March
5 30 day Review initiated
- April
5 30 Day public Review ends
- April
15, submit to oasis staff for member vote
- May
01 Membership two week review
- May
15 start member two week vote
- May
30 - member vote concludes.
Earliest Oasis Standard.