Prelim minutes WSRM TC Face To face Meeting at New Orleans
Marriott
wed, April 28, 2004,
from 9:00 am to 5:20 PM Central
Daylight Time
Thur April 29, 2004,
from 9:00 am to 12:00 Noon.
There was a conference bridge available on both days from 10:00 AM to 12:00
Noon CDT..
Tom Rutt agreed to take the minutes of this meeting.
1 Introduction. 2
1.1 Draft Agenda. 2
1.2 Roll Call 2
2 Approval of Meeting Minutes from
4/20 meeting. 2
3 Action Item Status Review.. 3
3.1 Action 033004-3 – (Jacques) 3
3.2 Action 033004-6 – (Tom) 3
3.3 Action editors-1 – (Marc and Doug)
Pending. 3
3.4 Action 041304-1 – (Jacques) 3
3.5 Action 041304-2 – (Iwasa) 3
3.6 Action 042004-1 – (Jacques)
Pending. 4
3.7 Action 040201-2 – (Pete) 4
3.8 Action 040201-3 – (Tom) 4
3.9 Action 040201-4 – (Tom) 4
3.10 Action 040201-5 – (Jacques) 4
4 Public review comments from OASIS
Panel Discussion. 4
5 Editors Draft .993 Status Review.. 5
6 Status of Public Review.. 5
6.1 Comment 9.2. 5
6.2 Comment 7.10. 7
6.3 Comment 7.11. 9
6.4 Comment 7.12. 10
6.5 Comment 9.1. 10
6.6 Comment 3.14. 11
6.7 Comment 3.16. 12
6.8 Comment 3.17. 12
6.9 Comment 7.6. 12
6.10 Comment 7.9. 13
6.11 Comment 8.1. 13
6.12 Comment 8.2. 13
6.13 Comment 8.3. 14
6.14 Comment 8.4. 14
6.15 Comment 8.5. 15
6.16 Comment 9.3. 16
7 New Comments from Sunil 16
8 Tony Graham editorial comments: 21
9 Liaison activities with EbMS - joint meeting. 28
10 Sunil new issues. 30
11 Planning for Future CD Balloting. 30
12 Review of Homework assignment
status. 31
13 Draft resolution of CF public
review comments. 32
14 Paper in response to Chris Ferris
Presentation at OASIS Symposium.. 37
15 FAQ.. 38
16 Discussion of RMP in Soap Terms. 38
17 Planning for Future CD Balloting. 39
To insert
|
First
Name
|
Last Name
|
Email
|
Role
|
Company
|
Voting
Level
|
|
Joseph
|
Chiusano
|
chiusano_joseph@bah.com
|
Member
|
Booz
Allen Hamilton
|
1
|
|
Jeff
|
Turpin
|
jturpin@cyclonecommerce.com
|
Member
|
Cyclone
Commerce
|
1
|
|
Jacques
|
Durand
|
jdurand@us.fujitsu.com
|
Member
|
Fujitsu
|
1
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
1
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC Chair
|
Fujitsu
|
1
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Member
|
Hitachi
|
1
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Member
|
Hitachi
|
1
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
1
|
|
Junichi
|
Tatemura
|
tatemura@sv.nec-labs.com
|
Member
|
NEC
Corporation
|
1
|
|
Alan
|
Weissberger
|
ajwdct@technologist.com
|
Member
|
NEC
Corporation
|
1
|
|
Abbie
|
Barbir
|
abbieb@nortelnetworks.com
|
Prosp
Member
|
Nortel
Networks
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
1
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
Secretary
|
SAP
|
1
|
|
Pete
|
Wenzel
|
pete@seebeyond.com
|
Member
|
SeeBeyond
|
1
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Secretary
|
Sun
Microsystems
|
1
|
|
Tony
|
Graham
|
Tony.Graham@Sun.com
|
Member
|
Sun
Microsystems
|
1
|
|
Chi-Yuen
|
Ng
|
cyng@csis.hku.hk
|
Member
|
University of Hong Kong
|
1
|
Meeting was quorate
Motion to approve Minutes of last meeting from Bob F, Doug B
seconded.
No opposition 4/20 minutes approved.
Jacques took action item to propose new FAQ text for the ws-reliability
features. –
Close by taking text from Sunil’s slides for the faq
Need a general question on how can ws reliability be used with other ws
reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.
Tom Rutt agreed to send a suggested question and proposal out regarding WS reliability composition. closed
Ø
Marc G and Doug B to updated issues list to
reflect agreements in CD .992.
-
open
- Jacques will send an email to initiate email discussion on poll response for fault conditions
· treatment
of aborted out-of-order seq
From Jacques Durand <JDurand@us.fujitsu.com> on 14 Apr 2004 00:15:05 -0000
Closed will discuss with issues
- Iwasa to consolidated agreed comments in text with
change bars against CD .992. A list indicating which meeting minutes’agreed changes were applied should also be included.
· Groups -
UpdatesListFromCD10Mar2004-0.992.pdf uploaded
From kiwasa@jp.fujitsu.com on 20
Apr 2004 14:41:05 -0000
· Groups -
WS-Reliability-2004-04-19.pdf uploaded
From kiwasa@jp.fujitsu.com on 20
Apr 2004 14:40:08 -0000
closed
Ø
Action: Jacques will propose the text changes to
the document to remove retry parameters
Provided for the agreements section 1, still open for section 3 and the annex
Pete
will provide an input to the F2F on the RMP / soap processing model to help
resolve the XMLP WG’s concern.. Include a proper definition of RMP
Done
– spawned New action item on Jacques and Pete
Tom
should put general document restructure on the agenda.
done.
Spawned
Jacques action item on document restructure
Tom
took an action a proposal to clarify when the Receiving RMP may need to send a
SOAP fault to close the WSDL level response.
done
Jacques
will take an action to write a proposal to try to resolve Martin C’s comments.
done
The
group formulated a set of public review comments.from the presentation by Chris
Ferris:
Cf1: Two schemas and namespaces are unnecessary
for two soap versions.
Cf2: Why are soap faults not used for RM-Fault?
Cf3:
Not Acking until delivery to the application causes unnecessary delays?
Cf4:
Unclear if the spec can compose with WS-Addressing or WS-MD?
Cf5:
Persistence model will not work on devices with non volatile storage?
Cf6: Mandatory Expiry time requires
synchronization of clocks:
Cf7: There is unnecessary complexity in the spec,
headers have unnecessary elements making them larger than necessary?
Tom
Rutt provided draft resolutions for discussion by the TC (see discussion
below).
Sunil
moved to accept all changes in editors draft .993 and its associated schema,
Alan seconded.
No
opposition, motion passes.
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6524/DraftPublicReviewOutcome.htm
10:30 12:00
Noon – Issues and Editorial comment
resolutions
|
9.2
|
Weissberger/Jacques
|
agreed text not yet applied
|
Faults for Aborted Ordered
Deliver
treatment
of aborted out-of-order seq
Action on Tom and Iwasa to
provide final text to explain new group abort error..
|
Out
of order sequence:
We
talked about two Issues that are not unrelated,
yet after review, I believe only one remains:
-----
Issue 1:
Should
the Receiver warn the Sender that an out-of-order sequence has been
aborted on the Receiver side, due to a reason other than message expiration?
(in case of message expiration, the Sender can - generally - deduce the
failure).
Position
1: This can't be more than just an optimization, as the reliability
contract would not be broken anyway (would not cause delivery of un-ordered
messages !)
And also we never rely on error messages for critical RM logic.
Note also that any further "quantitative" aspect of RM (e.g. about
max length of
out-of-order sequence) is out of scope for V1 (line 103, sec 1.2)
Position
2: This is more than just an optimization, as it is a special failure case
with potential high cost if not dealt with as efficiently as possible:
without knowledge that a sequence has been given-up, cumulative and useless
resending (and new sending) may overwhelm the Receiver.
We fault individual messages for various reasons, including lack of storage
resource,
so why not fault such a multi-message failure?
Opinion:
In case a Poll request is used by the sender, it does not cost much to give
notice of the failure (see example in Issue #2 below) in the poll response.
So even if we see this notification as no more than an "improvement" (Position
#1)
we can fault the dropped messages in the response.
But when callback is possible - and requested - should the Receiver send:
(a)- nothing at all
(b)- a special PermanentProcessingFailure for the entire group (so will that
look like responses we do for "singleton" groups?)
Agreed on New RM-Fault type to indicate the
failure of an entire group. It MUST be
sent by Receiving RMP for any request on that aborted group.
In the poll response the final reply range
will indicate that fault code, with the range of sequence numbers which were
not delivered by the Receiving RMP.
Faults will continue to be sent for each
message received after the group is aborted.
Name of new fault should be “GroupAborted”
Ø
Action: Iwasa and Tom will provide text for the
new fault code and the reference to it in the section of text Alan cites.
Ø
Action: Sunil will update schema for new fault
code in the message processing failures sector.
c)-
a PermanentProcessingFailure for each dropped message.
I personally favor (b) as a consistent complement to my opinion in poll request
case. A MAY or a MUST? I think again its just an optimization, so a MAY is OK.
-----
Issue 2:
When
we talk of generating Faults, and how to get them to Sender in case neither
callback or response pattern is possible. In that case, Polling is the only way
a
Sender can get faults generated on Receiver.
Well,
it appears that the Poll response can actually give the fault code,
so the issue is moot(so much for me).
A response to a poll about an aborted sequence, (assuming Position 2)
would look like:
<Response
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
soap:mustUnderstand="1">
<SequenceReplies
groupId="mid://20040202.103832@oasis-open.org/">
<ReplyRange from="0"
to="5"/>
<ReplyRange from="6"
to="15" fault="wsrm:PermanentProcessingFailure"/>
</SequenceReplies>
</Response>
NOTE:
should we have a new fault code: "InvalidGroupId" for requests
concerning groups that are non-existent (possibly because already terminated?)
|
7.10
|
1025-1030: Example in which
SOAP Fault may also convey an RM Acknowledgment requires a confusing or
impossible processing order. (Process RM headers, remember that an Ack needs
to be sent, continue with header processing and SOAP Body validation and
finally "application processing space outside the realm of the receiving
RMP".) How does the RMP know when all processing has been
completed, then intercept a possible SOAP Fault in order to attach its Ack?
|
open
|
Action Item to Tom Rutt for
proposing better text.
Re: [wsrm] response to action item to clarify soap
faults and WSRMresponses
Jacques too action item to
incorporate the latest proposal from Tom and Pete into a new section on request/response.
|
Tom
Rutt clarification of soap faults and RM faults:
This
is the proposed text changes, taking into account Pete Wenzel's comments:
Clarification
of Soap Faults and wsrm:response
Lines
1025 – 1030
“
“Example
case 1:
For
the WSDL Request/Response operation type, an operation request which was
successfully delivered by the receiving RMP to the receiving application may
result in an application-level Fault, (e.g., one specified in the WSDL
description for the operation), to be returned.
In
such a case, when the response reply pattern is in use, the SOAP fault message
associated with this application-level Fault MUST carry the Acknowledgment
indication in a wsrm:Response element within its Soap header.
This
is required so that the Sending RMP gains knowledge of the successful Delivery
of the Reliable message request, even though the operation encountered an
application-level fault condition associated with the processing of the WSDL
request/response operation.
“
line
1031 - 1047:
“
*Example
case 2:*
A
message with an RM Fault indication MUST NOT be delivered to the receiver by
the receiving RMP. In this case, when the Response RM-Reply pattern is in use,
a WSDL operation response will not be available for the receiving RMP to return
with the RM-Reply including the RM-fault indication. In such a case, the
Receiving RMP MUST cause an wsrm:Response to be sent in the header of a
soap:fault message.
This
same condition arises when the message in the request is a duplicate of a prior
delivered message with Duplicate Elimination in use. The Receiving RMP, in such
a case, when the Response reply pattern is in use, has no meaningful WSDL
response to return for that WSDL request/response operation, so it MUST cause a
soap:fault to be returned. The difference in behaviour with this duplicate
elimination condition, is that an RM-Fault indication is not sent for that
request in the soap:fault message, but an acknowledgement indication is sent.
In
cases where a receiving RMP MUST NOT deliver a WSDL request/response operation
request to the receiver, that receiving RMP MUST initiate the return of a SOAP
Fault message, associated with that request, as follows:
* If the RM-Fault indication was due to a
problem with the request
header element, a SOAP client fault MUST
be returned.
* If the RM Fault encountered was due to a
problem with processing
by the receiving RMP (including the
inability to return a response
due to Duplicate Elimination), a
soap:server fault must be returned.
“
Tom:
Need to clarify that we do not provide reliability on the response of wsdl
request response operation, thus if duplicate is send due to sender not
receiving first response, the receiving rmp will not have the prior response
buffered to send in this condition.
Bob:
we need to get rid of redundant sentences because people may think there is a
difference.
There
are special considerations for WSDL request response operations.
Jacques:
the concept of wsdl request/response should occur in a specific section early
in the document explaing how wsdl request/response operations would be designed
to work with ws reliability. Need an
explicit section of wsdl request response operations, and this fault text could
go there.
Ø
Jacques took an action item to propose this new
subsection on special considerations for wsdl request/response operations.
|
7.11
|
1990: Remove appendix if there
is nothing to say here; the sole item listed is already done (App A)
|
agreed not yet applied
|
Agreed to delete appendix D
futures list
|
|
7.12
|
The specification contains
no reference to the schemas.
|
agreed not yet applied
|
The two schemas should be
listed in the normative appendix, and introduced at an appropriate location
in the text, perhaps at the beginning of Section 4
Agreed to have a new
normative appendix which points at the schema URL. It also has to have the precedence
statement copied from the schema.
At publication time the
OASIS staff can decide to place the actual schema text.
|
|
9.1
|
Sunil/Jacques
|
agreed, not yet applied
|
Retry Parameters
reworded section on agreements
Jacques presented his
proposal.
for now update second level
in poace, to move to new level 1 section after Jacques reorganization action
item.
|
Comment
9.1 – new proposal for rm-agreement first level section.
Jacques
presented his new proposal.
Agreed
to remove (s1) from section 2.4 of proposal.
There
was discussion on the description of the expiryTime agreement parameter.
Bob:
the precision of the expiry time should not be finer than the expected skew of
the clocks between sender and receiver.
Perhaps using a timestamp, plus a time to live interval, would help
this.
Jacques:
on the wire it is date/time currently.
Bob:
if the purpose is to have a course control we could get away with a course
interval.
Bob:
we always have a clock, but it may be grossly skewed from other system’s
values. We are creating a new cause of
protocol failure if we rely on clock synchronization.
Bob:
what degree of clock skew can our protocol tolerate.
Tom:
we need a solution for the case of the receiving RMP having the wrong year (say
2003 instead of 2003) set by the sys admin after a disk restoration.
Bob
if you have two values you give the receiver more information. If the sender sends time time plus time to
live interval the receiver can calculate
the average skew.
Leave
open
Alan:
two values are required to cover the case of a resend.
Defer
discussion of time skew issue until Thursday morning.
Jacques
continued reviewing his proposal for new section 2.
Change
line 114 “smallest scope allowed” to “smallest applicable scope allowed”
Tom:
currently the constraints are in the protocol section.
Jacques
moved, Bob seconded to incorporate his proposal with the changes noted above.
|
3.14
|
Line 408-406: If a
reply pattern is sent that had not been previously agreed upon, it will be
rejected, with a Fault message: Non Supported Feature returned to the sender
Alan suggested: MUST BE
|
agreed in princ but text
still
needed.
|
Doug B: we tend to not use
word reject, for this is to the sender end. This needs to use the
deliver operation terminology.
Agreed in principle.
Leave wordsmithing for action item.
Jacques: the text regarding
MUST send for faults should be stated in a general manner to accommodate
polling or delayed callback. A single
section to explain what “sending a fault” means.
“Sending an RMfault must be
interpreted differently depending on the reply pattern in use.”
|
Ø
Jacques took
action item to add appropriate text to also clarify that an RM-Fault must be
returned if the message cannot be
delivered because the requested reply pattern is not supported
|
3.16
|
Section 3.3. Guaranteed
Message Ordering Failure Case
|
closed see 9.1
|
Line 563-565: Is the
decision to abort ordered delivery totally implementation dependent?
Can we specify a Maximum Persistance time parameter for a received out of
order message, so that after that time receiver aborts ordered
delivery. Otherwise, a skimpy implementation could give up almost
immediately vs a robust implementation trying to recover for a much longer
time after receiving multiple out of order messages without receiving any
retransmitted sequential messages
|
|
3.17
|
Line 726: groupExpiry Time
attribute:
Clarification: No
mention whether this parameter can be changed. Suggest forward reference
to line 1148- 1149. 6. Line 1148- 1149
|
agreed not yet applied
|
Suggest reference to
appropriate section
Add the following to both
groupexpiryTime and groupMaxIdleTime definitinons in 4.2.1.1
“Constraints on allowed values
for this attribute are specified in section 5.
|
|
7.6
|
Section 1.5: Examples are
placed in an awkward location. Should appear after the protocol &
features are described. Suggest moving them to a non-normative appendix
|
agreed , text position to
be determined
|
Agreement to move examples
to a later section or annex of the document, position to be determined.
|
|
7.9
|
569: Sequence Number is not
a Feature; it is simply a mechanism used to Implement Guaranteed Message
Ordering. Should not be given equal status to the other 3 features.
|
open
|
Defer to the general
document restructuring exercise.
.
|
Ø
Jacques took an action on where to move the current
section 3.4, with perhaps a re-title of section 3. Jacques will also propose a new document
structure to accommodate this and other problems he encounters
|
8.1
|
Only one area needs major tree
surgery: section 1.7 should be merged with appendix II and placed in its own
top level section. This is the part of the doc that threw me most.
|
accom by 9.1
|
new section on reliability
agreement
|
|
8.2
|
Line 101 - 114: editorial: delete
all these lines as its castes too much doubt on the spec
|
agreed changes not applied
|
<JD> How about
rewording instead like:
"Reliability is often
associated with QoS quantitative measures, in areas other than Web services
(e.g. networking). Thresholds such as rate of failures, minimal size of
persistent store, average latency, and more generally quantitative measures
that may appear in service level agreements, are out of scope for this
version."
<MC> fine
</MC>
|
|
8.3
|
Line 150 - 271: editorial:
I find it strange that we launch into example messages without any form of
introduction. Maybe better to insert a paragraph to explain
a scenario from whish these messages are derived. And also there really should
be an fuller explainaion of a the reliability elements.
|
accom see 7.6 and 8.x
|
<JD> we have some
explanation at the end of each example. We could move this up before
introducing each example, instead of after.
<mc> the text is very
terse. If you look at other specs they really walk though all the relevant
elements and explain what is going on </mc>
[Jacques Durand] Let us ask
our editor, I think there was some intent to give an up-front flavor of the
headers, that the reader could go back to as s/he progresses through the
spec. (I expressed in the past my preference to see these examples at the end
of doc, but can understand this rationale. Now, question remains how much
walk through can we do up-front without much knowledge of the spec...)
Discuss with document reorganization,
could move examples into a later section or annex.
agreed to put examples
later in the document.
|
|
8.4
|
line 358: editorial: the
whole of section looks out of place. It uses a lot of terminology that has
not yet been introduced. It is also strongly related to appendix II. I
suggest moving the whole of 1.7 into a new top level section after section 5
(i.e. make it a new section 6) and then merge in appendix II.
|
accommodated by 9.1
|
<JD> the problem with
moving the agreement definitions after Sec 5, is that we refer to them
throughout the spec, starting with Sec 3, when introducing RM features. Why
not have a new section between Sec 2 and Sec 3 (i.e. previous Sec 3 becomes
4, etc.) However, when doing so I would not import the entire Appendix A/II
up front, as I think it is unsettling for the reader who expects to get right
at the core features with as little distraction as needed... so I would
provide some introduction material on the rationale for adding capability
info to WSDL, and the approach recommended, and then refer to Appendix A for
the hard stuff. Also if we combine the agreement and the f&p
stuff, clearly state that even if they complement each other, they don't need
each other. </jd>
<mc> maybe i missed
something but thr agreement stuff is sort of meaningless without a way to
express it. Granted there may be many ways to do this, with f&p being one
of them. If this is what you mean then fine. </mc>
<jd> We thought this
over, and concluded that agreements can remain abstract and still be
meaningful here: in fact, it is the only proper way to connect to
"outside" agreements while keeping their representation open. We
describe our RM features like: "if <agreement-item-XYZ> is enabled
(or has value ABC), then the message protocol must look like this, the
behavior must be like that." Just describing the protocol on teh wire
was ignoring the agreement aspect. Also, some features like resending
messages (and related parameters, like # of retries, etc) would not even
appear in the message protocol. We needed to be able to talk about the
behavior they cause even if they don't have a concrete representation.
</jd>
<mc>Generally though,
the agreement stuff is very detailed, and the detail is launched into without
any overview of rationale. This is my main concern so even putting that in
its own section may not help. </mc>
|
|
8.5
|
line 444: editorial: I
suggest adding a paragraph or two here that does provide a very high overview
of the model. The subsequenst sub section dive into details without giving
the reader an overview on which to elaborate. I suggest using the text in the
pre-Tc version that was published:
"In the Reliable
Messaging Model described in this document, the sender node sends a message
to the receiver node directly (i.e., intermediaries are assumed to be
transparent in this specification). The receiver node sends back an
Acknowledgment message to the sender node. Figure 1 shows this model.
Figure 1 Messaging Model"
This should provide enough
context
|
agreed not yet applied
|
<JD> Isn't that very
similar to the first bullet item of 2.1 ?
No problem with this
rewording though.
But the transition to 2.2
(and Figure 1) probably calls for another sentence like:
" the basic exchange
patterns described in 2.2 derive from the above messaging assumptions.
Reliability features
defined in this specification will in turn rely on these
patterns."
<mc> fine </mc>
|
|
9.3
|
|
|
Document Reorganization
|
Jacques
took action item (previously recorded) to propose document restructuring.
· Comments sent on behalf of Sunil
From "Bob Freund" <Bob.Freund@hitachisoftware.com> on 28 Apr 2004 17:12:50 -0000
· Editorial changes to examples in Section 6.2
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on 28 Apr 2004 03:44:54 -0000
More
editorial comments:
1.
Changes to the Examples
- XML
payload uses namespace prefixes such as xlink, xsi, schemaLocation which are
never used.
Agreed
editorial change
- HTTP
Headers for RM Requests mention a POST with a ‘/abc/servlet/wsrListner’. It
will be good to make it more meaningful such as ‘/abc/servlet/wsrEndpoint’ or
‘/abc/servlet/wsrExampleEndpoint’.
Agreed
editorial change
- For
Callbacks, response POST context URI doesn’t match the replyTo URI in the
request
agreed
editorial change
- Why
did we have 2 separate examples (Example 3 for Ack and Example 4 for Fault) for
the same Poll Request (Example 3). It will be good if we can collapse Example 4
into Example 3 by adding the ReplyRange sub-element (for msg. 15) into Example
3’s <SequenceReplies> element.
Agreed
editorial change
- It
will be good to add the attribute last=’true’ to the 3rd Message in
Example 6 (SequenceNum Element). This way we will have illustrative example to
show the usage of this (‘last’) attribute.
Agreed
editorial change
2.
Figure Updates:
Most
of the figures use the word ‘Application Layer’, we need to better quantify
what we mean by ‘Application Layer’ or say something like ‘Application
Layer/SOAP Processor’.
Agreed
that the word application and application layer need to be changed to more
abstract terms (perhaps producer and consumer).
Ø
Jacques took action item to propose appropriate
change to using word application (perhaps producer/consumer).
3.
Chapter 1/Section 1.6/Polling RM-Reply pattern/Line 352
Just
add the word “poll” to better qualify it, i.e., make it “contained in the underlying
protocol response to this poll request or in a separate …”
Agreed
editorial change
4.
Chapter 2/Section 2.3/Lines 483.
Line
483 states “This Message Identifier relies on the notion of group. A message
always belongs to a group”.
The
above is incorrect. A message can be independent/singleton or in a group.
We
need to reword it.
Agreed
to following editorial changes:
Line
413 414 488 of .993, Delete
parenthetical statements
Line
1193 – change “singleton groups,” to “groups”
5.
mustUnderstand attribute used in tables 1, 9,12 must use lower case ‘m’ for
mustUnderstand. It will be much better if we can qualify it as
soap:mustUnderstand so as to distinguish this attribute with other RM specific
attributes.
Agreed
editorial changes
6.
Chapter 4/Section 4.2.1.1/’number’ attribute.
Reference
to number attribute on lines (734,735) should start with a lower case
‘n’.
agreed
Lines
732-733 should be changed as follows:
The
value of this attribute MUST be unique within the same group, and the
combination of MessageId’s groupId attribute value and SequenceNum’s number
attribute MUST be globally unique to be used as a Message Identifier.
Agreed
to change first para of section 4.21 to:
“Two
messages with the same groupID, MUST NOT use the same sequence number value.”
7.
Chapter 4/Section 4.2.1.1/’last’ attribute/Lines 751-758
- ‘False’/’True’
should be ‘false’ & ‘true’
- We
also need to mention that
Agreed
to: Remove “(Default value)” and add new
sentence: “When this attribute is not present,
its value defaults to false.
We
also need to mention that the first message in the group can also have this
attribute with a value ‘true’, i.e., to indicate the first message in the group
is also the last message, something similar to a singleton message.
Jacques:
this is useful guidance; however has no normative impact on an
implementation. Perhaps a separate
implementer’s guide could hold such statements, along with rationale for the
decisions we made.
Bob:
sometimes our guidance to the implementer breaks up the flow of the normative
text. We can go for a more concise
readable document with normative specification.
Jacques:
very few OASIS voters are developers.
Such reviewers may not appreciate implementation guidance.
Jacques
it does not hurt to have a guideline document.
As I do my action item for the document reorg, I will put any such
removed guidance text into a preliminary cut at the implementers guide. And will place Sunil’s sentence above with
that text.
8. Section
4.4/Response Element.
Comments
on replyPattern
1) replyPattern on
line 908 must start with a lower case ‘r’
Agreed
editorial change.
2) Did
we decide that this is optional? I remember being it mandatory to avoid
potential errors. Schema says it mandatory.
Agreed to align text with
schema delete “which defaults to the value “Response”
Mention
the cardinality of attribute clearly when describing the attribute itself. We
do mention sometimes at the element (that has this attribute) level. Examples:
1) Mention that
replyPattern attribute (line 937) is a MUST (see above comments).
2) Mention that
groupId attribute of NonSequenceReply (line 961) is a MUST.
3) Mention that
groupId attribute of SequenceReplies (line 972) is a MUST.
4) Mention that the
fault attribute of ReplyRange element is optional (Line 992)
1,
2, 3, and 4 above agreed as editorial changes
9. Section 4.4.1
(NonSequenceReply)
While
the ‘fault’ attribute is listed in Table 13, it is not described below. We need
to describe this something similar to ‘fault’ (lines 992-995) attribute for
ReplyRange. We need to mention that this is optional too.
Agreed
editorial change add:
(2) fault
attribute
This attribute is
used to indicate a Reliable Messaging Fault code which was encountered while
processing the
message. The Receiver RMP MUST NOT include this attribute for an acknowledgment
indication.
10. Section 4.5/Fault Codes/Lines 1008-1012.
I
think this paragraph needs to be reworded. A suggested one would be:
Agreed
to delete following text
“
The WS-Reliability protocol
does not directly map our Reliable Messaging Faults to the
SOAP Fault model.
The SOAP Fault model is used
for reporting faults due to the request payload, which fits the
SOAP fault model better. Thus
a response may have a SOAP Fault message, but the reason for
the SOAP fault would be due
to problems associated with the WSDL operation message payload.
(E.g., A problem with the
soap:body of a request message or the inability of the Receiver RMP to
return the WSDL response in
the soap:body of when using the Response RM-Reply pattern).
“
and
add appropriate FAQ question with the following answer:
“
The
SOAP Fault model was not used for RM Faults because:
- SOAP
Fault model doesn’t support batching of Faults which this protocol requires.
“
This
text should also go into the new implementer’s guide document, along with other
rationale text for the decisions we made.
Alan:
I am concerned that such changes might delay the time to final specification.
Tom:
we probably will have enough technical changes to justify another review round
anyway.
11. Section 4.5.1/Line 1037 should be:
“Invalid Message Format Faults”. (plural Faults).
Agreed
editorial change.
12.
Will the final version have Appendix C(Revision History)? If not, could we
remove it from the specification move it to a different document.
Agreed
to remove appendix C and instead maintain a new parallel document on the server
with this information.
· Editorial comments on 0.993
From Tony Graham <Tony.Graham@Sun.COM> on 28 Apr 2004 03:08:17
-0000
Section
1.1, Purpose of WS-Reliability
--------------------------------------
Line
74
Change
"The purpose of WS-Reliability is to address reliable messaging
requirements,
which become critical" to "WS-Reliability addresses
reliable
messaging requirements, which are critical".
agreed
Line
77
Change
"This specification is intended as an initial proposal for
defining
reliability" to "This proposal defines reliability".
agreed
Section
1.2, Scope and Definition of Reliable Messaging
-------------------------------------------------------
Line
81
Change
to "This specification focuses on the SOAP layer and
envelope.
It defines reliable messaging as the mechanism supporting
any
of the following requirements:".
Line
88
Change
to "Within this scope, this specification supports:".
Line
92
Change
to "Some features are out of scope of this specification, yet
this
design is compatible with their implementation.
They are:".
Section
1.3, Notational Conventions
-----------------------------------
Lines
121-127
The
formatting on this list doesn't make it very clear. Should it be
redone
as a table?
Line
122
Change
"e.g." to "E.g.,".
Line
128
Add
the namespaces from the similar table in Appendix A and remove the
table
in Appendix A.
Section
1.5, Examples of Messages Compliant with WS-Reliablity
--------------------------------------------------------------
Remove
the "xmlns:xlink", "xmlns:xsi", and
"xsi:schemaLocation"
namespace
declarations and attributes from the examples since they are
unnecessary.
Remove
the XML Declarations since they are unnecessary.
Line
178
Change
"wsr-example.org" to "wsr.example.org" or
"example.org/wsr" to
properly
use the "example.org" example domain name.
Lines
182-183
Change
"No Duplicate Delivery" to "Duplicate Elimination" and
change
"Ordered
Delivery" to "Guaranteed Message Ordering" to match the terms
used
in line 90.
Lines
239-242
The
explanation should also explain the NonSequenceReply element.
Lines
229, 260, 262
Use
'straight' quotes instead of 'smart' quotes around attribute
values.
Section
1.6, Terminology
------------------------
Line
283
Change
"e.g," to "e.g.,".
Line
288, 304
Why
must the time be identifiable? Why is it
not sufficient to
just
preserve the order of submissions, e.g., in a queue?
Line
292
Move
to the next page (i.e., keep it with the following paragraph).
Line
294
Change
"Reliablity feature" to "reliability features".
Line
297
Remove
"A Message Identifier is".
Remove the comma after "header".
Line
302
Remove
"Message delivery is". Change
"deliver" to "Deliver".
Line
304
Change
"(application)" to "(e.g., the application)".
Line
316, 317, 319
"Acknowledgment
messages" are not defined. There
are now only
"Acknowledgment
indications".
Line
329
How
can a "Reliable Messaging Fault Indication" signal a failure to
receive
a message when this specification "expects that the transport
layer
will not deliver a corrupted message" (line 1308) and there are
no
fault codes for non-delivery of messages?
Line
336
A
reply may now include multiple Acknowledgment Indications.
Line
340
Remove
one of the spaces in "in a".
Line
353
Make
the sentence begining "This polling pattern is generally
expected..."
into a note following the definition since this sentence
is
more a comment than a definition.
Line
355
Change
"behind the firewall cases" to "e.g., when behind a
firewall".
Lines
297 to 356
Reorder
the definitions to reduce the forward references:
Message
Identifier
Duplicate
Message
Message
Delivery
Reliable
Message
Acknowledgment
Indication
Acknowledgment
Message (new definition)
Reliable
Messaging Fault Indication
Reliable
Messaging Reply
Response
RM-Reply Pattern
Callback
RM-Reply Pattern
Polling
RM-Reply Pattern
PollRequest
Message
Section
1.7, The Reliability agreement
--------------------------------------
Line
357
Change
"agreement" to "Agreement" to match the capitalization
style of
similar
headings.
Line
362
Change
"notify operations on" to "and notify operations at".
Line
366
"between
the application layer, the sender and receiver RMPs" does not
scan.
Section
1.7.2, RM Agreement Items
---------------------------------
Line
388, 390, 392
Change
"period" to "period.".
Lines
388-406
Should
this list be a table with "Name", "Value", and
"Definition"
columns?
Section
1.7.3, Messaging Scope of Agreement Items
-------------------------------------------------
Line
415
Change
"is affecting" to "affects".
Section
2, Messaging Model
--------------------------
Line
450
Change
"message" to "messages" twice.
Line
458
Change
to "The three ways to send back an Acknowledgment message or a
Fault
message are as follows:".
Line
461, 467, 474
Remove
"With this message reply pattern,".
Line
463
Change
"The figure 1" to "Figure 1".
Line
468
Change
")," to ")".
Line
469
Change
"The figure 2" to "Figure 2".
Line
488, 491
Change
"In case" to "When".
Section
3, Reliability Features
-------------------------------
Line
499
"Business
payload" is undefined.
Section
5, Operation Aspects and Semantics
------------------------------------------
Line
1263
Number
the table and make this the title for the table.
Line
1271
Why
are "Supported" and "Disallowed" so large?
Appendix
A
----------
Line
1604
Change
the section numbers to "A.1.", etc.
Line
1605
Add
a space after ")".
Line
1606
Change
"supported/required" to "supported or required".
Line
1628
Merge
this section into Section 1.3.
Regards,
Tony
Graham
Ø
Action: Iwasa to apply all editorial changes
from Tony’s mail, except for those he considers in need of discussion.
Met
jointly.
Alan:
can EBMS be used with WS-Reliability.
Ian:
today the answer is no.
Ian:
the main issue for discussion is how eb-ms can use ws-reliability in a future
version of eb-ms.
Tom:
we are trying to facilitate a-future version of eb-ms being able to use
ws-reliability.
Jeff
T: we would need to have a ws-reliability header in a message but used in a
non-reliable manner.
Jeff
T: they have a need for messageID but not for reliability purposes. We need a reference to a message ID.
Doug
B: There is a need to use message correlation features in eb-ms without need
for guaranteed delivery or duplicate elimination.
Iwasa:
The current spec has all three qos values optional. Guaranteed delivery, duplicate elim, and
ordered delivery are all optional. If
neither are present in an rm-request without syntax errors, there will be no
rm-reply under the current ws-reliability protocol. However, a header being broken would cause an
rm-headerFault returned.
Doug:
ref to message id in ws-reliability supports single or multiple references to
messages.
Doug:
this is ok.
Ian:
another discussion is how to reorganize grouping of the header blocks to work
out what is what.
Doug:
the ws-reliability TC has also discussed putting our header blocks in a common
wrapper header element.
Ian:
my point of view is that we could define a common style for having grouping
elements to identify which specs are in use.
Wss has a security container.
Sunil:
having wrappers might affect composition.
Jeff
T: having a wrapper can ease implementation. One handler can be dispatched for all
ws-reliability features.
Doug
B: the reason to ask the question here is to, if we agree, we can send a
message to the tab for a common style.
Matt
M: putting things with a common default namespace in the same header type can
ease implementation as well.
Jacques:
Hamid, in our TC, wanted a way for the rmp to make decisions without looking
into the soap body. He wanted to have an
attribute to put in the reliability header to distinguish whether an rm-request
is piggybacked with a rm-reply.
Sunil:
this is purely style concern, however I like it, because it puts a context
around the headers named simply request and response.
Ian:
this allows implantations which are not properly namespace aware. It allows for evaluation of an xpath by a
processor which is not fully namespace aware.
Jeff:
it helps the readability of the schema.
Ian:
if wsrm TC decides to add a common header wrapper (as WSS and each ws-caf spec
drafts) then Tom and I as chairs should send a note to the TAB to recommend a
common specification practice for OASIS specs.
Take
it as a public comment from eb-ms group on suggesting a common security header.
In
the future, when there are TC meetings collocated, we should ensure that the
only overlap time for eb-ms and wsrm TC is joint meeting time.
Sunil:
for a group we say qos should be the same for all messages in the group. If so, why do we have to send the qos
parameters every time. Why not send them
only on the first message for the group.
Jacques:
the first time the receiver receives a message from the group takes those qos
values and use them for the lifetime of the group.
Tom:
could send them until the first ack is seen by the sending RMP.
Will
discuss on Thursday.
Sunil:
if the receiver demands a qos level, but the sender does not assert it, how
does the receiver react.
Tom:
we discussed this in the past that the receiver can send a soap client fault in
this case.
Jacques:
but this will not work for wsdl one-way operation type.
Tom:
we decided this condition is out of scope of this spec.
Jacques:
receiver side only enforces reliability requirements visible in the
protocol. The concern Sunil is expressing
is out of the scope of this specification.
Tom
will send a pointer for the original issue resolution in this area.
Most
aggressive timing: assuming 3 implementations by May 10
May
29 : Final Editors draft posted
May
3 – member editorial review comments due
May
4 – TC votes for editorial changes, and to initiate final CD 1.0 ballot
May
5 – CD ballot begins
May
12 – CD ballot closes
May
14 – Submit package to OASIS for OASIS Standard Processing
Alternative:
to agree on all changes by May 4 TC meeting
Editors
post final review draft by Friday May 7.
May
11 meeting we vote on a CD 1.0 completely ready to go.
May
14 – submit to OASIS.
Ø
Action: Tom should put out a call for IPR
claims.
Look
at this further on Thursday.
Iwasa
produced draft .994:
Document
Description:
April 28,2004(WD0.994)
This
was updated for:
DraftPublicReviewOutcomeforMinutes.htm
with:
1.4,
2.2, 2.6, 3.17, 5.1, 6.1, 7.2, 7.3, 7.4, 7.5, 7.8, 7.11, 7.13, 8.2, 8.5,
and
editorial updates for examples as described in a minutes on 4/28/2004.
And
here are some comments:
2.5
*This was already resolved at 0.993:
7.12
Schema in appendix
*The latest schemas Needed.
Action:
Iwasa needs to make a new appendix, with the disclaimer for schema precedence
(as in the schema text) and a URL pointing at the current schema on the WSRM
server.
7.13
526: "nor to notify failure on the sender
side" should be "nor to notify
the RMP Sender of the failure".
*Replaced "RMP Sender" with
"Sending RMP"
agreed
7.13
527: "it's" should be
"its". Schemas:
"it's" (in comment blocks) should be "its"
*Schemas was not taken care of. Other items in
7.13 was implemented.
Sunil
has action item to apply comment 7.13 resolution to schema.
Ø
Action on Jacques: incorporate his new Agreement
section while doing the document restructure.
We
need to prepare a paper which rebuts the concerns of Chris Ferris, expressed in
his presentation to the OASIS Symposium, and provides a counter argument as to
the perceived problems with the WS-ReliableMessaging spec from Microsoft, IBM
and partners.
The
following was provided by Tom Rutt as a starting point for resolving the CF
public review comments:
Cf1: Two schemas and namespaces are unnecessary
for two soap versions.
Agreed:
Proposed
change:
remove
the soap 1.2 schema, and change the following lines on the soap 1.1 schema:
soap
1.1 schema has:
"
...
<xsd:schema targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"
xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"
elementFormDefault="qualified"
attributeFormDefault="unqualified" version="0.62">
<xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
schemaLocation="http://schemas.xmlsoap.org/soap/envelope"/>
<!-- 4WSRM Headers -->
<xsd:element name="Request"
type="wsrm:RequestType"/>
<xsd:element name="Response"
type="wsrm:ResponseType"/>
<xsd:element name="PollRequest"
type="wsrm:PollRequestType"/>
<!-- Describe the BaseTypes -->
<xsd:complexType name="HeaderBaseType">
<xsd:sequence>
<xsd:any
namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute
ref="soap11:mustUnderstand" use="required"
fixed="1"/>
<xsd:anyAttribute
namespace="##other" processContents="lax"/>
</xsd:complexType>
...
"
to
the folloing:
"
...
<xsd:schema targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/"
xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="0.62b">
<!-- 4WSRM Headers -->
<xsd:element name="Request" type="wsrm:RequestType"/>
<xsd:element name="Response"
type="wsrm:ResponseType"/>
<xsd:element name="PollRequest"
type="wsrm:PollRequestType"/>
<!-- Describe the BaseTypes -->
<xsd:complexType name="HeaderBaseType">
<xsd:sequence>
<!--mustUnderstand attribute for
soap version used must be present with value = 1 -->
<xsd:any
namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<!--mustUnderstand attribute for
soap version used must be present with value = 1 -->
<xsd:anyAttribute
namespace="##other" processContents="lax"/>
</xsd:complexType>
..
"
And add the following text to the spec, in the new annex pointing at the
schema:
When used with soap 1.1, the soap1.1 mustUnderstand attribute MUST be present
with value equal to 1 in all RM header blocks.
When used with Soap 1.2, the soap1.2 mustUnderstand attribute MUST be present
with value equal to 1 in all RM header blocks.
Cf2: Why are soap faults not used for RM-Fault?
The
SOAP Fault model was not used to report RM Faults is because:
- SOAP Fault model doesn’t support batching
of Faults which this protocol requires.
- While it is not illegal to send a Soap
Fault in an HTTP Request, it is unusual
to send a Fault in a request message.
Proposed
change: none required
Cf3:
Not Acking until delivery to the application causes unnecessary delays?
The
definition of delivery in the specification is abstract, and allows
implementation architectures using queues and other mechanisms not actually
requiring the ultimate receiving application to participate in the
acknowledgment procedure. Delivery can
occur as soon as the Receiving RMP can ensure that the delivery contract
associated with the request is satisfied (e.g., all prior messages in an
ordered sequence have been received). In
most cases delivery occurs immediately after receipt of the message.
The
initial contribution to the TC work had a protocol which returned an ack to the
sender as soon as the message was received (assuming it is not expired). However, this behaviour admitted failure use
cases where the sender would think the message was delivered, while a failure
condition after this ack, admitted cases where the message could not be
delivered (e.g., the receiving RMP has a processing failure while a received
messages is being held waiting for a prior message in an ordered sequence).
Also,
the state machine was simplified significantly by sending the ack only when the
receiving RMP delivers the message (e.g, makes it available to the next
processing element in a chain by putting it in a queue).
Proposed
change: none required
Cf4:
Unclear if the spec can compose with WS-Addressing or WS-MD?
An
important consideration in design of the WS-Reliability protocol was to have it
be composable with any other web services protocols which define the use
of soap header elements.
WS-Reliability
defines elements to be sent in Soap
headers . Our header elements only
contain parameters essential for the operation of the WS-reliability
protocol. For example, WS-reliability
defines a reply to element for the sending Reliable Message Processor to convey
a call back address for the Reliable messaging reply. This address is independent of any other
reply mechanisms used for other protocols (e.g., WSDL response is not
influenced by the WS-Reliability reply To parameter). The syntax for this element is URI, since
that way of referencing a soap endpoint is independent of any specific
adressing or message delivery specification.
We
want ws-reliability to compose with many other mechanisms.
The
WS-Reliable messaging protocol, since it relies on ws addressing From address
as the callback destination, does not support a callback to a different
endpoint than the from address.
Proposed
change: clarification text under discussion in TC
Sunil
suggested we might want to modify the schema to allow for extensibility in the
syntax for the Reply to attribute.
Tom
stated we do not want to tie the syntax down to either WS-addressing or the new
WS-Message Delivery format for endpoint references.
Cf5:
Persistence model will not work on devices with volatile storage?
WS
Reliability does not explicitly prescribe persistence requirements.
The
persistence requirements (e.g., holding a received message in a buffer until
all priors have been delivered in an ordered sequence; holding a list of
integer ranges of sequence numbers which have been delivered, or faulted) are
identical for WS-Reliability protocol and WS-ReliableMessaging protocol.
A
device with volatile storage (e.g, memory goes away when power goes away) can
meet the requirements of the protocol as long as its storage remains in
tact. Because messages are only acked
when delivered, in cases where failure of the non-volatile storage results in a
message not being delivered, the sending RMP will not receive an ack. The sending RMP can notify the producer of
the message that the message is not assured to have been delivered.
Proposed
change: TC is checking if there is any mention of persistence remaining, which
will be removed.
Cf6: Mandatory Expiry time requires
synchronization of clocks:
The
precision of the expiry time selected by the sending application needs to be
selected to allow for normal skews in system clock.
Although
there may be some merit in designing a more robust mechanism to deal with
excessive clock skews, the expiry time mechanisms used is consistent with other
specifications, such as ebxml Messaging, ws lifecycle management.
Propose
change: under discussion by the WSRM TC.
Cf7: There is unnecessary complexity in the spec,
headers have unnecessary elements making them larger than necessary?
The
TC charter required the WSRM TC to produce a requirements document to determine
features, required by members of the TC, to be met by the protocol.
These
requirements led, amongst other features, to the need for three RM reply
patterns to cover the use cases identified in the requirements.
The
WS-Reliable messaging specification, from Microsoft IBM and partners, does not
support all the use cases identified in the WS-Reliability requirements (e.g.,
it does not support polling for RM replies), thus its protocol may seem to be
less complex.
However,
conformance claims can be made by an implementation to any valid subset of
WS-Reliability features. A receiving RMP can return a notSupportedFeature
rm-fault code in response to a request for features it cannot satisfy. Thus a WS-Reliability implementation needs
only be as complex as required by the use cases it is designed to support.
The
cost of adding necessary indicators of features requested in request header
elements is minimal in terms of header size and processing complexity.
Proposed
change: None required.
Cf8 Spec does not state a Reciever MUST
acknowledge all delivered messages with each acknowledgment indication.
WS-reliability
requires an ack to be sent for all delivered messages. It states “If a
receiving RMP receives a message with AckRequested element, the receiver MUST
send an Acknowledgment message even when the message is a duplicate, and if it
has already been previously delivered.”
Sending
the complete ack history for a sequence along with every ack indication was
deemed unnecessary for the WS-Reliability protocol.
Ws-Reliability
has a polling mechanism to allow the Sending RMP to request the acknowledgment
status for all the messages sent within a Group. .
Proposed
change:
TC
is currently working on clarification wording which covers the polling case,
where the ack is made available for a poll response (but not sent until the
poll is received).
Cf9 There is unnecessary implementation details
in the spec.
The
spec has several, non-normative, implementation guidance notes.
Proposed
change: TC has agreed to move many of these non-normative implementation notes
into an informative companion document.
The
TC agreed to prepare a paper to address the concerns express by Chris Ferris at
the presentation, and to provide a balanced comparison, from our point of view,
with the Microsoft IBM and partners WS-Reliable messaging specification.
Points
to be included in our comparison:
Lack
of polling support
Why
is “to” field needed for reliability.
If
both From and Reply to are present in the ws-addressing header, it is not clear
where to send either the ack or the fault.
They
do not send any policy directives on the wire.
Since there is no policy property defined for indicating duplicate
elimination or other qos contracts, there is no specification on how this is
accomplished.
The
spec does not address rm processing failures of any kind.
Unclear
what behaviour of NACK is when a fault is already sent for a particular message
in a sequence.
Poor
support for groups with one message.
Batching
of faults is not supported.
Sending
an ack at time of receipt admits potential failure cases. Sending the entire ack history is not sufficient.
(we should give one or more use cases which show their deficiency)
Their
spec is not clear with respect to a wsdl oneway operation how the destination
for the ack is determined.
The
schema is not fully explained in the spec, and there appear to be
inconsistencies
Ø
Bob F took action to lead a team to provide an
initial draft of the comparison paper of WS-Reliability/WS-ReliableMessaging,
for review by the TC. Sunil and Jacques
joined the team.
Agreed
that we should come back to addressing the FAQ after we prepare the paper.
No
discussion at this meeting.
Def
of
Reliable Messaging
Processor (RMP):
A module capable of
processing and enforcing Reliable Messaging as described in this
specification. With regard to
the transmission of a message from one RMP to another, the former
will be act in the role of
“sender” and the latter in the role of “receiver”.
Pete:
Need to relate this definition to base terms which have a normative definition
in the soap specification. We also have
to relate this to the diagrams.
Sometimes they are called nodes, which is a soap term.
Is
an RMP an entire soap node, or soap processor, or is it just a slice of a soap
node. This impacts the interfaces the
rmp must expose and use to communicate with other processing elements.
Jacques:
It could be a soap node, but does not have to be. It could be implemented as a Java handler,
which extends a soap node.
Pete:
we need to give it a definition which is flexible enough to allow alternative
implementations.
Jacques:
the definition of deliver was left abstract for this reason. It does not necessarily mean reaching the
ultimate application. It could be
another handler in a chain within a node.
We
agreed to change “application” to “producer” and “consumer” throughout the
document.
Fig
7 and fig 4 are not consistent.
These
figures should be updated to use the terms “producer” , consumer and Sending
rmp and receiving rmp.
Pete:
is the consumer role only on the receiving rmp end?
We
need to formally define “producer’ and “consumer” in the spec.
Ø
Action: Jacques will lead a team to ensure the
terminology used in the spec is consistent with normative terms in the soap
spec. Pete W will work with Jacques to
provide a proposal to resolve this.
April
29: Iwasa posts all agreed edits in a new .995 editor’s draft.
May
4 morning: Jacques posts a change barred .996 editor’s draft for review by TC
(including a rough draft implementers guide holding non-normative text removed
from .995 draft.
May
4 evening - resolve all comments at TC meeting with editing instructions for
editors.
May
6 - Final Editors draft posted resolving all comments.
May
10 – member editorial review comments due
May
11 – TC votes approval of CD 1.0 ballot and vote to submit to OASIS at call
May
14 – three letters from members on “using the spec”
May
14 – Submit package to OASIS for OASIS Standard Processing
Sunil
expressed concern that there is not enough time for member review of the final
editor’s draft between May 7 and May 11.
Bob:
Jamie clarified that once it is submitted for OASIS review, no changes are
allowed by the process (no edits at all).
We are doing restructuring and may editorial text changes. We should have a proof reading
Tom
will schedule 2 hour Tuesday phone calls for the next four weeks 5:30PM to 7:30
PM EDT.
12:
noon – Meeting adjourned adjourn.