ebxml-msg — archive

[System]

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. > >