Re: [ws-rx] [i090] Use of offered sequences unclear in current spec

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

Paul Fremantle <paul@wso2.com> wrote on 01/24/2006
09:54:02 AM:

> It has no more or less information than in the previous case. I am
> guessing again, that most implementations will associate the offered
> sequence with either the ReplyTo EPR or the incoming sequence.

Which replyTo?  The CS - which I think might
be anon most of the time
for performance reasons?  The ReplyTo on the
first message - which might
actually be the last one received?  (And in a
non-InOrder DA world would
be processed last) Is there some kind of EPR comparing
to know when the ReplyTo of one particular message
matches the
ReplyTo EPR that will be used for the offered sequence?
 Do ref-p's 
matter in that comparison?

> Those are 
> the logical options based on the lack of any other information. (I'm
> assuming no out-of-band config). But again the spec doesn't define
this. 
> However, the case is just the same in the case of no offer. The 
> Responding RMS (RRMS) has to create a sequence. I'm guessing that
> without out-of-band information the RRMS is going to send the CSM
to the 
> ReplyTo. It still has to decide for which response messages to use
that 
> sequence. I don't believe that Offer adds any further unclarity to
this 
> part of the spec.

Paul, yes the RRMS needs to decide which response
messages should use the
offered sequence but the problem with the current
spec is that I think
there are two different ways to interpret the current
wording around
offer:
1 - it applies to all replies regardless of the wsa:ReplyTo
on each
    individual message
2 - it applies just to replies targeted to some EPR
(see above's Q's)
3 - it applies to all messages (replies or new msgs)
from the RMD to
    the RMS (this is actually what it says
today, IMO)

The problem with '1' is that it assumes that all of
the wsa:ReplyTo's
are linked and can handle RM state-sharing.  I'm
not comfortable with
that assumption.
The problem with '2' is that we have no idea which
EPR we're talking
about.  
The problem with '3' (aside from what problems '2'
has) is that 
whichever EPR we choose may not live long enough to
deal with the 
non-reply messages that it encompasses.

Keeping offer in the spec, like it or not, is going
to make
people make some assumption about when the offered
sequence can be
used - if the RM spec doesn't clear up that assumption
then we have
an interop nightmare.  If we clear up the spec
and point people towards
interpretation #2 or #3 and make it clear which EPR
we're talking about
then things might not be so bad, although I'm still
not really clear
on how we choose the right EPR or tell people how
to compare them.

-Doug