David, Please see below. Cheers, Chris David Fischer wrote: >
> Chris, >
> Wow, what a proposal! I *think* your way would work but it is such a
> substantial change to the way the spec reads now that I would vote NO just on
> those grounds. Version 1.1 is supposed to be only bug fixes. Your proposal
> also does not address (intentionally) what I perceive as a requirement --
> end-to-end MSH level receipts. We don't want to have to go all the way to the
> application to determine whether or not to retry. Each developer would have to
> write this code into EVERY APPLICATION. No, we can't do things that way. This
> is Transport Layer functionality. Let us not confuse application layer with application here. By application layer I mean a level of software that is above the MSH in the stack. If you have an eBusiness Server, the MSH is only a component of that. The determination can be left to that level since we are concerned not with defining a specification for an implementation of an eBusiness Server, but of a wire protocol and required behavior of an abstract MSH.
>
> If you don't want to call Delivery Receipts a part of Reliable Messaging, I
> don't really care. I don't want to quibble over semantics. Whatever the
> process ends up being called, MSH level Delivery Receipts are essential and the
> ability to retry on lack of a Delivery Receipt is just as important. This was
> all in the specification prior to multi-hop and it needs to stay there. DB's
> proposals do just that and I support them. As I have said before, we don't need to support end-to-end retries if we have (as I know we all understood) a consistent application of RM semantics at all MSH nodes involved in a message exchange. We never discussed end-to-end retries above and beyond p2p retries in TR&P until you raised this issue post 1.0 publication. If anything is v2.0, then I would think that end-to-end retries over and above p2p RM is. >
> Regards, >
> David Fischer
> Drummond Group. > >
