Next Steps in Reliable Messaging (was RE: Different Levels of Rel iable Messaging)

[wearing a co-chair hat]
 
I'm very pleased that this discussion has been so productive and
illuminating.  It's getting a little too deep into possible specs and even
implementations for the WSA WG's purposes, however. 
 
I would appreciate it if there was discussion of what we would need to do to
actually do something with the reliable messaging idea in the context of the
W3C's Web services activity, however:
 
1 - How does it fit into the WSA architecture document as drafted?  Is there
a well-developed body of theory or practice that the document to reference?
(TCP comes to mind ... the point of this might be to replicate TCP's
semantics at a higher architectural level, e.g. where there are non-TCP/IP
networks in the mix, discrete message delivery mechanisms use higher-level
protocols such as HTTP, etc.)
2 - What would be the scope of a WG that would actually draft a reliable
messaging spec?  
3 - Is the scope/timing limited enough so that we could -- assuming they
were interested -- propose that the XMLP WG take this job on, or will it
require specialized expertise and/or a lot of time that XMLP doesn't have?
 
Thanks!

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Saturday, December 14, 2002 7:36 PM
To: Burdett, David; www-ws-arch@w3.org
Subject: RE: Different Levels of Reliable Messaging


<Ricky> 
This is what our disagreement is.  I think the sender should report to the
application that delivery is "in-doubt".  (not "failed")
</Ricky>



3. The destination restarts, finds the message, sends the ack and starts
processing it. 
4. The sender receives the ack and has to tell the application that the
message for which it had just reported a delivery failure had actually been
received and was processed - not a desirable outcome

Alternatively by specifying a time out and basing the retries on that you
know, with a high degree of certainty, that even if the message is picked
up, it won't be processed and therefore you are much less likely to have to
report the a delivery failure and then have to reverse it.


<Ricky>
Lets say the message has been picked up before time expired, and the
receiver site is down before the ACK message is sent.
Now even though the sender keep resending message until time expired, he
still cannot conclude the delivery failure
</Ricky>