COmments on Doug contribution

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: COmments on Doug contribution

Comments on Doug contribution (--08-07-drb-diff):
I only list below the points I have problems with - agree with all other updates I am silent about...
The most controversial and far-reaching (beyond editorial) are the changes in 2.5.2 and 2.5.3, see my last comment.
We need to have a once-for-all discussion on this...

Regards

Jacques

L352: This bullet is redundant with RM contracts that are defined afterward.
Also, this kind of summarized requirement is risky: it is likely to clash with more detailed requirements
coming later. (e.g. is it about "in-order" messages only? if yes, such an arbitrarily scoped statement is condusing, and if applicable

if not, it suggests that duplicates that are "valid" must be delivered too for non-ordered groups.
I suggest to remove, or at minimum to change into:
" A receiving RMP MUST NOT invoke the Deliver operation on a message that is either invalid or expired."

Footnote 1 (p5):
As an RMP functions encompass those of a SOAP processor, I think it is going to far to say that
"the Sending RMP would take no special action based on it (HTTP errors)".
I'd cautiously limit that statement to :
"The reliability features described here do not rely on the interpretation of
non-SOAP responses."

L391 and Footnote 2 (p6): The removed bullet was not questioning the need for correlating messages for the
user side (Producer), but reminding of properties specific to this MEP, that we assume will be supported along with this MEP by an RMP (even if only needed in some particular cases). Correlation is actually assumed in the SOAP 1.2 definition (by the "state machine" on the sender side). So this removal was not really justified I think.

L438-441: this small paragraph is unclear. I see an attempt to link these reply patterns to the RMP operations:
my expectation was that we don't need to do so: these reply patterns can be *defined* in terms of protocol only
(exchange patterns RMP to RMP). The fact that they may map to particular usages of RMP ops, will be
conditioned by how these ops map to the SOAP MEPs, but that is specified elsewhere and does not need encumber
the definition.

Section 2.5.2: I do not understand this very significant update:
it imposes that only SOAP One-way MEPs be used for Callbacks (both request,
and RM Reply) To me this is an unnecessary restriction: why do we need it? (I don't recall the TC accepted this)
Even if in theory it seems more appropriate, when using SOAP request-response, to always use Response Reply Pattern, a Callback or a Poll could be used there also, with no harm for the RMP or pain for its developer.

(and deleted Table in 5.2 clearly acknowledged that, so far)
I would rather leave that decision to users.
In particular, restricting to use One-way for callback RM Replies seems unwarranted:
as 4.4 suggests, RM Replies can be piggybacked on any business message, and that could be a separate request-response going the other way. Bundling of RM Replies works also for Callbacks (Section 6), and there may be many reasons why someone may want to use this feature, e.g. a callback RM Reply could be sent back for acknowledging many reliable messages, some of them may be carried by request-response MEPs, some by One-way MEPs (that may be determined by the operations these messages may bind to, e.g. as determined by SOAP or WSDL bindings.) But all these may be sent in the same group and be subject to the same RM policy. Some Callback RM Replies could

aslo come back before even the business response is sent back, on a SOAP request-response.
I have same general concern for restrictions introduced in 2.5.3.