Title: RE: [wsrm] Proposed resolutions for ChrisF issues 3,4,6,8,10
inline <JD>
I also merged-in more of C.F. comments with my related proposals.
Jacques
-----Original Message-----
From: Doug Bunting [mailto:]
Sent: Thursday, July 15, 2004 5:11 PM
To: wsrm
Subject: [wsrm] Proposed resolutions for ChrisF issues 3,4,6,8,10
1) and 2) follow-up:
<JD> in addition to proposed resolution (previous emails), we need to fix - or explain - the
way we name these operations: we call them currently "RMP operations" at various places,
but as noted these abstract operations are not necessarily supported by the RMP.
So to be more precise we could rename them (QoS operations? or transfer operations?)
or just explain that this naming does not mean all these ops are supported by an RMP.
</JD>
3) lines 151/5 and 250/1 should have a normative reference to the OASIS
SOAP Message Security 1.0 spec not "WS-Security"
==> As agreed (I believe) during the teleconference, make the change Chris
suggested and reference the specification in both places using the correct
term.
4) line 489/90 reads: ... Why is this only a RECOMMENDATION?
"It is RECOMMENDED to NOTresend a message for which an RM-Reply with one of
the following Fault types has been received:".
==> change to
"A Sending RMP MUST NOT resend a message for which it has received an
RM-Reply with one of the following Fault types:"
I am not sure where group termination due to an error should be covered
though expect that would be somewhere in chapter 5. I do agree both the
sending and receiving RMP should terminate a group as soon as such a fault
is identified (for the receiving RMP) or received (for the sending RMP).
This is complicated because the sending RMP may have to retry or poll
before it shares this understanding, meaning the receiving RMP cannot
"forget" the group immediately.
<JD> I guess the reason that is only a recommendation, is that
preventing such resending is not essential to the RM protocol.
(E.g. similarly, we never say that as soon as an Ack is received, any resending MUST stop.)
It is just not paramount (nor always feasible?) to strictly enforce this, implementation-wise, although this is an optimization.
As for the dis-ordered sequence of which one message has been faulted, it is indeed
an optimization that we have not done, to terminate the group when one of its
messages has been faulted as above (we currently would wait for the faulted message
to expire, to terminate the group.)
So we could update 5.1.3.5 (Termination by ordered failure) by adding to
the "triggering event" line (both in sending RMP and receiving RMP): "...or a message
is faulted with one of the codes mentioned in section 3.2.1"
</JD>
5)
line 166 defines "RMP" in terms of a SOAP node (as defined by SOAP1.2)
and yet it is intended that the protocol be capable of being used with
SOAP1.1 which does not have the term defined. It seems odd to define such
an important term using the formal definition defined for only one of the
two protocols for which the WS-R protocol is intended to be usable. Is
this suggesting that a conformant RMP must be capable of processing
SOAP1.2 messages?
<JD> Good point, although the "node" definition in SOAP 1.2 Part 1, section 1.4.1
appears to be a general one (not depending on 1.2 specific features).
So we could use the term "SOAP processor" instead as Tom suggests, and say
that in case of SOAP 1.2, it is a SOAP node, and in case of SOAP 1.1,
it complies with similar requirements:
"...enforcing the rules that govern the exchange of SOAP messages and accesses the services provided
by the underlying protocols through SOAP bindings."
I think what we want to convey in the RMP definition is that (1) an RMP implements SOAP protocol and some underlying binding so that it can do messaging, and (2) an RMP understands RM SOAP headers.
</JD>
[C.F.]...It makes for a cleaner specification if one defines
behaviour in terms of destination and source because it is entirely
feasible that a component might implement only one of those roles. As
defined, WS-R requires that a conformant implementation of an RMP
implement both roles which would limit its applicability to certain use
cases such as small footprint devices or in cases where reliability was
only needed in one direction. Also, what is with the "a subset, or
superset thereof". What does that mean exactly?
<JD> I think these concerns were addressed in the latest contribution (July 7)
which is not the one Chris used.
- new section 2.2 ("RMP operations") explicitly says an RMP can be implemented
for sending, and/or receiving (lines 256-257)
- the "subset/superset" part was removed from the def.
</JD>
6) line 171/2 defines the term "reliable message". This seems unnecessary.
==> change
"Reliable Message:
A message for which some level of reliable delivery is required."
to
"Reliable Message:
A SOAP message containing a <wsr:Request> header block."
Note: I am comfortable with mixing such concrete definitions with the
various abstract terms we use to illustrate our model. If others would
prefer our definitions have a consistent abstraction level, what do they
suggest for this definition?
<JD> fine with me: only the terms that refer to notions that the spec does not
want to define further (yet wants to define properties about), need be "abstract".
In the present case, this forward reference is OK (since we say that the glossary
can do forward references.)</JD>
8) line 217 [actually 221-225] defines the term "PollRequest Message" ...
leave out the embellishments.
==> change
"PollRequest Message:
A polling message for Acknowledgment Indication(s). A Sending RMP may send
a PollRequest Message for polling of Acknowledgment Indication(s)
regardless of RM-Reply Pattern of the original Reliable Message. For
example, the Sending RMP may send PollRequest Message to retrieve
Acknowledgment Indication for a message originally sent using Callback
RM-Reply Pattern."
to
"PollRequest Message:
A message the Sending RMP sends to the Receiving RMP, requesting RM-Replies
for identified earlier Reliable Messages. Support for this message is
REQUIRED as part of the Poll RM-Reply pattern (see section 2.5.3). This
message MAY also be used to augment other RM-Reply patterns."
10) line 265/8 reads: ... getting perilously close to implementation detail
"An RMP which supports both Submit and Notify MUST be able to associate a
failure notification (Notify) with the related submitted payload(Submit).
In case the notification of payload is supported, the RMP MUST be able to
associate a received payload(Notify) with a previously submitted
payload(Submit)."
==> This text or something similar was the subject of an earlier discussion
in the TC which may not have completed to everyone's satisfaction. I would
prefer deleting this paragraph. It is only an indication to the developer
how to design their API were they to choose a direct rendering of the RMP
component.
<JD> but this is just the counterpart requirement to what we say earlier in same section
about the need to associate a Respond invocation to a previous Deliver invocation.
We know an RMP MUST be able to do so (this is part of the semantics of Respond).
Why then is this OK while it is not OK to require also that on the Sending side,
similarly, a Notify invocation must be associated with a previous Submit invocation?
</JD>
thanx,
doug
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
