Re: Multi-hop reliable messaging

[Nikola Stojanovic <nhomest1@twcny.rr.com>]

<David>
In the mean time comments are really welcome.
</David>

Here they are:

<Comment 1: page 12>
Picture is not right. Like in FC5: "eventually give up and send message 12".
If you give up you cannot send Ack, you should send "Delivery Failure".
Also, note on FC 6 about "Ack on Ack", why would that be needed?
</Comment 1: page 12>

<Comment 2: page 14, 15>
Why would UC 9 need Ack back on Msg 5 to Hub 1 and UC 8 doesn't need Ack
back on Msg 2 to Party 2? Also, why wouldn't Hub send Msg 7 to Party 2,
which is also Final Ack? Are you assuming not reliable on the way back
between Party 2 and the Hub, but reliable between the Hub and Party 1?
</Comment 2: page 14, 15>

<Comment 3: page 16>
"Implicit and explicit acks must not be mixed on a single conversation over
one hop". How does this statement relate to the UC 10 and why this
restriction?
</Comment 3: page 16>

<Comment 4: page 17>
This should be UC 11 not UC 10. Also, if Ack is on Msg 9, do you need Msg
11, which is Ack back on Msg 8 to Party 2 (similar to "Comment 2")?
</Comment 4: page 17>

<Comment 5: page 18>
"Requires Message 4 to contain "Ref to" to Message 2". I would establish
this as "ImplicitAcknowledgment" Pattern for all Implicit Acks and move it
earlier in the doc.
</Comment 5: page 18>

<Comment 6: page 19>
Why wouldn't Msg 5 (Wait) work as an Ack (like Msg 2 on page 17)? Is it
because of rule on page 16?
</Comment 6: page 19>

<Comment 7: page 20>
"Need a concept of a lifetime". I agree.
</Comment 7: page 20>

<Comment 8>
It looks like a good start. I can imagine that if we would add shapes of
Headers for Msgs that flow (or at least for representative cases) it would
be very clear and useful doc for implementers and POC-like people.
</Comment 8>

Regards,
Nikola