RE: [ws-rx] [i089] a revised proposal

[Doug Davis <dug@us.ibm.com>]

I believe MSFT has the todo to go off
and write down how anon ReplyTo is supposed to work.  In the last
interop call we had there were quite a few questions raised about how things
should work and we need those addressed.  I believe some of them were:

How does the offered seq get shutdown?
 ie. how does the RMD send a terminate back to the RMS?
How can the RMD close the offered sequence
if it needs to?
What should happen when a late arriving
(already ack'd) message arrives at the RMD? What should the response be?
Can there be two sockets connected to
the RMD at the same time and both sending the same message?  What's
the response to in each case?
If request msg #2 is acked (back at
the RMS) but response msg #2 isn't acked (back at the RMD) how can the
RMD resend it?  I think its possible that the RMS can get to a point
where it received response msg #2 but the ack for it was lost.  So,
RMS thinks all is well, but RMD doesn't.  Unless the RMS resends a
message (but why would it when it thinks all is well), then the RMD is
stuck.  Can't resend and can't close the sequence.
What specific changes to the spec(s)
do we ned to make to clear up these issues?

If we end up keeping Offer around just
for the anon replyTo case (which I believe you said is the main reason
for keeping it), but we can't explain how anon ReplyTo is supposed to work
without hacking up the protocol, I'm not sure its worth keeping it - esp.
not when there are other solutions around that do allow these scenarios
to work without messing up RM.

thanks,
-Doug

"Marc Goodner" <mgoodner@microsoft.com>

02/21/2006 01:12 PM

To	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] [i089] a revised proposal

Only time? I think the scenario
is pretty clear so what are the issues with it you see that would prevent
it from working? 
 
If you are suggesting that
you want to do interop on it first then are you likewise suggesting that
this issue (and I would infer i090) should be deferred from being closed
until then?
 
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 21, 2006 10:04 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089] a revised proposal
 

Yea, I figured you'd say that :-)  that's why I wanted the latest
text in the issue list.  W.r.t. your assertion that anon replyTo can
work w/RM - only time (and your proposal) will tell :-)
-Doug

"Marc Goodner" <mgoodner@microsoft.com>

02/21/2006 12:55 PM

To	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] [i089] a revised proposal

 

I can’t support this. I think some of the scenarios we have been discussing around the use of Offer demonstrate that you can get a reliable response back when using an anon wsa:ReplyTo value. I think the proposal would be OK if the last sentence, beginning “Note” was struck.
 
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/

 

---

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Wednesday, February 08, 2006 9:31 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] [i089] a revised proposal
  

For issue 089, I'd like to offer this revised proposed text (same basic
idea just different wording):

After line 441 of [1] add: 

Messages sent using this protocol MUST NOT use a wsa:To value that would
prohibit the RM Source from retransmitting unacknowledged messages. For
example, using WS-Addressing's anonymous IRI, without any additional transmission
mechanism, would restrict an RM Source's ability to re-establishing a new
connection to the RM Destination when a re-transmission of a message is
needed.  Note, that this implicitly impacts possibles values used
in other places - for example, in wsa:ReplyTo when responses are expected
to be transmitted reliably.

thanks, 
-Doug 

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16095/wsrm-1.1-spec-wd-08.pdf