Re: [ws-rx] i089 proposal

[Tom Rutt <tom@coastin.com>]

Christopher B Ferris wrote:

>
> Paul,
>
> Please see my comments inlined below.

I seek a clarification of the Doug D proposal.

With Doug D latest proposal, the ReplyTo epr with polling URI has to 
have at least one
unique ref parm.

Does that mean that whenever a message is destined to that epr, as a 
response to get message,
those ref parms from the epr must be present as soap headers on the 
response?

Tom

>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> Paul Fremantle <paul@wso2.com> wrote on 05/04/2006 02:55:55 AM:
>
> > Doug
> >
> > Some comments:
> > > I'm not promoting a general solution - not exactly :-). What I'm
> > > promoting is a solution that
> > > solves all of the various use-cases that I believe the RM spec should
> > > address. In developing
> > > the solution however, many people have noticed that it can work even
> > > when RM (the resend
> > > until acked part of RM) is not turned on - and that is true but
> > > nothing was added to the solution to
> > > make that happen.
> > However, you have defined (elsewhere) reliability very widely, 
> including
> > getting messages to endpoints that aren't reachable. So this 
> argument is
> > really circular. Effectively what is says is that because I've included
> > all the use cases for any polling situation in my requirements, I've
> > ended up designing a system that supports them, even without any
> > relation to the reliability mechanisms the WSRM spec has focussed 
> on. So
> > effectively your proposal is completely orthogonal to the existing RM
> > spec. If we took your proposal, changed the namespace, and published it
> > separately, it would be a valid standalone spec that could be composed
> > with RM or not.
> > > In fact, it would take a lot of effort (and IMO hurt the proposal) if
> > > it was modified
> > > to only work like Paul's proposal - he tried very hard to tie his
> > > proposal to RM sequences, and
> > > as a result he limited the RM scenarios he can support
> > I actually believe that my proposal can support almost any scenario.
> > However it focuses on the core scenario and requirement that we see in
> > the marketplace - which is supporting anonymous clients doing in,
> > in-out, and in-multi-out MEPs against a server with a well-known 
> endpoint.
>
> But, your proposal does not support "out-only" RM.
>
> > > - and he will end up changing the core RM processing model too.
> > The phrase "core RM processing model" is very dangerous if not
> > disingenuous. The specification does not define the RM processing 
> model.
> > It is up to each implementor to build a processing model for RM that
> > supports the protocol. And so what you consider important about your RM
> > processing model may not be what I consider important. The use of this
> > term, as if it were something sacrosanct and untouchable, is 
> misleading.
> > If we focus on the actual use cases, scenarios and implementation
> > details then the discussion will be much more open.
>
> If we analyze the proposals in terms of the RM use cases, then I think 
> that
> Doug's proposal is a more complete solution. The fact that it also 
> satisfies
> non-RM uses cases is besides the point. It could, and maybe should, be 
> scoped
> to RM use cases only.
>
> >
> > For example, I think what you mean in this case is that either side can
> > create a sequence with the other side whenever it wants, and that in my
> > proposal this isn't true as the Client must Offer a sequence to the 
> Server.
> >
> > Of course in real life this is completely untrue. In the current spec
> > the server cannot actually create a sequence with an unreachable
> > endpoint. Simply because it can't reach it. My proposal doesn't change
>
> Actually, that isn't quite true unless you consider the transport binding
> as one with the RM processing. The act of transfering a message is 
> orthogonal
> to its purpose/intent. Clearly, when RM is engaged, the application can
> "send" a message at a time when the destination endpoint is unreachable
> because of a network partition. How is that different?
>
> > this. It is up to the TC to decide whether they want to support this
> > aspect or not. However, it has very little to do with "changing the 
> core
> > RM processing model".
> >
> > I deliberately didn't try to solve this because as you have shown the
> > only way to do this is to create a complete alternative polling model
> > under which the server can communicate with the client. In order to
> > connect to an anonymous client, you need a context under which to
> > communicate. You simply have a choice - use the existing context (the
> > sequence) that the RM spec defines, or create a new one. The EPRId 
> model
> > that you have proposed effectively adds a new context that the server
>
> What makes you think that the server must "keep track" of this? The 
> server
> has to "keep track" of nothing, IMO.
>
> > must keep track of. Not only is this adding a new set of state to be
> > managed, but nowhere in your spec does it define the lifecycle of this
>
> What state?
>
> > state. So it is undefined how long the server must keep track of this
> > state. The server must buffer messages under this EPRId context and has
> > no defined mechanism for cleaning this state up. There is no fault 
> model
> > around this. There is no way for the client to signal a clean up of 
> this
>
> That is because that is an implementation detail. This spec covers
> the protocol aspects exclusively, not the implementation details.
>
> > state. So your proposal adds significantly to the implementation of an
> > RM agent, and also adds a considerable amount of ill-defined machinery
> > that will come out in the interoperability testing and in 
> implementation.
> >
> > My proposal is designed to work with the existing context model that RM
> > defines (a sequence) and to make minimal changes to how the server and
> > client manage and use that context. Because of the work the TC has done
> > in tightening up the lifecycle of this context and in interop testing,
> > my proposal builds on top of an already stable and interoperable base
> > with a small and clearly defined addition.
>
> So does Doug's proposal, IMO.
>
> >
> > Paul
> >
> > >
> > >
> > > *Doug Bunting <Doug.Bunting@Sun.COM>*
> > > Sent by: Doug.Bunting@Sun.COM
> > >
> > > 05/01/2006 03:00 PM
> > >
> > >
> > > To
> > > Doug Davis/Raleigh/IBM@IBMUS
> > > cc
> > > ws-rx@lists.oasis-open.org
> > > Subject
> > > Re: [ws-rx] i089 proposal
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Doug,
> > >
> > > I may be struggling with a similar issue to Marc though I would phrase
> > > it differently: Could you please describe how your "general" solution
> > > fits into the Charter[1] under which our group was formed?
> > >
> > > thanx,
> > > doug
> > >
> > > [1] <http://www.oasis-open.org/committees/ws-rx/charter.php>
> > >
> > > On 30/04/06 17:57, Doug Davis wrote:
> > > >
> > > > Marc,
> > > > First, I'm glad that I think we're all in agreement that a polling
> > > > solution is the right solution for these issues - I think that alone
> > > > is progress. So, as you say, the question then becomes a matter of
> > > > placement of function. Up to now I think most people have chosen to
> > > > ignore this issue. Yes some groups (like WS-BaseNotification or
> > > > WS-Management) saw the issue and defined their own domain specific
> > > > solutions, but they are just that - domain specific. As you say in
> > > > your note, a more foundational architectural solution is a better
> > > > approach. So, is RM one of those specs? RM clearly isn't domain
> > > > specific and it deals with transfer of messages between endpoint 
> - so
> > > > far so good. As I've said several times, I don't think its a stretch
> > > > to think of reliability as more than just resend until acked. Right
> > > > now RM already deals with reaching unreachable endpoints - but we've
> > > > been thinking of it limiting itself to 'unreachable' meaning
> > > > temporarily down - or poor networks connections. I really don't 
> think
> > > > its hard to see anon endpoints as being part of that grouping - 
> there
> > > > really isn't much of a difference. In all cases the other side isn't
> > > > guaranteed to be there - the only thing that's special about 
> this case
> > > > is how the connection between the two endpoints is established -
> > > > beyond that everything else is the same (at least for our proposal -
> > > > Paul's doesn't keep everything else the same but that's a different
> > > > note :-).
> > > > Perhaps I didn't say it correctly, but its not that I think its RM's
> > > > job to get the anon/sync world to look as much like the async 
> world -
> > > > what I meant to say is that we wanted our polling solution to allow
> > > > them to look the same to the code that makes use of it.
> > > > thanks,
> > > > -Doug
> > > >
> > > >
> > > >
> > > > *"Marc Goodner" <mgoodner@microsoft.com>*
> > > >
> > > > 04/28/2006 04:32 AM
> > > >
> > > >
> > > > To
> > > > Doug Davis/Raleigh/IBM@IBMUS,
> > > <ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: [ws-rx] i089 proposal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I’m certainly against banning anon. Why is it the mandate of RM to
> > > > “get the anon/sync world to look as much like the async world as
> > > > possible”? Your proposal makes it clear that is what your goal 
> is, but
> > > > that is also foremost in my mind why it has nothing to do with RM.
> > > > That statement clearly scopes the problem you are trying to 
> solve as a
> > > > foundational architectural concern below the level of RM.
> > > >
> > > > 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:* Friday, April 28, 2006 1:28 AM*
> > > > To:* ws-rx@lists.oasis-open.org*
> > > > Subject:* RE: [ws-rx] i089 proposal
> > > >
> > > >
> > > > I think this scenario is required for RM. At the last f2f we talked
> > > > about how an RMS may need to create new sequences for a variety of
> > > > reasons - one of which was because people wanted to be able to 
> create
> > > > a new sequence based on the soap version, but there are lots of 
> other
> > > > reasons people may need to create 'em. IMO, the use of the anon EPR
> > > > should not impact these types of decisions - remember we're 
> trying to
> > > > get the anon/sync world to look as much like the async world as
> > > > possible. If we allowed anon EPRs to impact our RM
> > > > processing/decision-making model then we would need to explore 
> banning
> > > > the use of anon, which I believe is something your against.
> > > > -Doug
> > > >
> > > > *"Marc Goodner" <mgoodner@microsoft.com>*
> > > >
> > > > 04/28/2006 04:14 AM
> > > >
> > > >
> > > > To
> > > > Doug Davis/Raleigh/IBM@IBMUS,
> > > <ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: [ws-rx] i089 proposal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Doug, is that scenario required for RM or polling in general? As 
> soon
> > > > as you start talking about a server side RMS establishing a sequence
> > > > to an un-addressable client I think you are beyond RM. You can’t
> > > > establish inbound communications from a server to an un-addressable
> > > > client without RM so why is this an RM problem?
> > > >
> > > > If we are looking to add a tightly scoped polling mechanism to 
> RM for
> > > > specific scenarios this one would not be high on my list.
> > > >
> > > > 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:* Friday, April 28, 2006 1:05 AM*
> > > > To:* ws-rx@lists.oasis-open.org*
> > > > Subject:* Re: [ws-rx] i089 proposal
> > > >
> > > >
> > > > I do believe that the scenario you're talking about is a 
> required one
> > > > but I would phrase it
> > > > a bit differently. An RMS (whether its the client-side RMS or the
> > > > server-side RMS) needs
> > > > to be able to follow the same RM processing model. And part of the
> > > > processing model
> > > > is the ability to decide "if", "when" and "how" to use RM. As we 
> talk
> > > > about in the Q&A
> > > > section of our proposal, an RMS having the option of choosing to
> > > > decide which RM sequence
> > > > to use, when to create new ones, or even when to use RM at all 
> are all
> > > > part of the RM
> > > > processing model and those aspects need to be maintained even in 
> these
> > > > anon cases.
> > > > In your proposal you put the burden on the RMD to make a lot 
> decisions
> > > > on behalf of
> > > > the RMS, that's quite a change to the RM processing model and I have
> > > > no idea how the
> > > > RMD could ever know all it would need to know to make those 
> decisions.
> > > > For example, how
> > > > would it know when a new sequence is needed by the RMS? That is 
> why I
> > > > believe our
> > > > proposal is a better fit for RM - it allows the RMS to retain all of
> > > > the same logic and choices
> > > > that it has in the async world. Our proposal simply re-establishes
> > > > the backchannel that
> > > > the RMS (on the server side) is looking for - nothing more. Once 
> that
> > > > is there, it is then
> > > > back to "standard operating procedures" - the RMS can do whatever it
> > > > would normally
> > > > do.
> > > > thanks,
> > > > -Doug
> > > >
> > > > *Paul Fremantle <paul@wso2.com>*
> > > >
> > > > 04/27/2006 05:51 PM
> > > >
> > > >
> > > >
> > > >
> > > > To
> > > > Marc Goodner <mgoodner@microsoft.com>
> > > > cc
> > > > wsrx <ws-rx@lists.oasis-open.org>
> > > > Subject
> > > > Re: [ws-rx] i089 proposal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > If the TC isn't attached to this scenario then this section can be
> > > > deleted. The scenario is simply when you want to send unreliably but
> > > > receive reliable responses. I've heard this stated as a 
> requirement in
> > > > some scenarios, but WSO2 doesn't have any pressing scenarios of 
> this ilk
> > > > so we would be happy either way.
> > > >
> > > > Paul
> > > >
> > > > Marc Goodner wrote:
> > > > > So is an RMS engaged at the client side or not? This is weird, 
> why
> > > would
> > > > > the infrastructure on the client side decide to do this?
> > > > >
> > > > > Marc Goodner
> > > > > Technical Diplomat
> > > > > Microsoft Corporation
> > > > > Tel: (425) 703-1903
> > > > > Blog: http://spaces.msn.com/mrgoodner/
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > > > Sent: Thursday, April 27, 2006 12:57 PM
> > > > > To: Marc Goodner
> > > > > Cc: wsrx
> > > > > Subject: Re: [ws-rx] i089 proposal
> > > > >
> > > > > Marc
> > > > >
> > > > > This is the case where the client is making an offer but not
> > > creating an
> > > > >
> > > > > outbound sequence - thats all. A client offers a sequence, and 
> then
> > > > > reliably gets messages from the server that are buffered under 
> that
> > > > > sequenceID.
> > > > >
> > > > > Paul
> > > > >
> > > > > Marc Goodner wrote:
> > > > >
> > > > >> I still don't understand why offered sequence is being used 
> in the
> > > > >> explanation. If this is going to usually be used with an offered
> > > > >> sequence I'd like to understand how, that isn't explained in 
> my mind.
> > > > >>
> > > > > If
> > > > >
> > > > >> it is applicable for any sequence, offered or not, I'd like to
> > > > >> understand that as well. The current text only confuses me in 
> its use
> > > > >>
> > > > > of
> > > > >
> > > > >> the term and I'm afraid your explanation below isn't helping 
> me get
> > > > >>
> > > > > past
> > > > >
> > > > >> it. Perhaps comparing the two modes would be a better approach.
> > > > >>
> > > > >> On 4.2, "Offer a sequence without the overhead of requesting 
> one"? I
> > > > >> don't understand. The text refers to the RMD requesting a 
> sequence
> > > > >>
> > > > > from
> > > > >
> > > > >> the RMS, but it sounds like this is an unreliable request so 
> doesn't
> > > > >> that mean there is no RMS at the client? Isn't this about the 
> service
> > > > >> acting as an RMS and the client acting as an RMD? So the pattern
> > > would
> > > > >> be client sends one way message to service (GetMessage?), 
> response is
> > > > >> Offer, then client sends a response to the response of 
> Accept? What
> > > > >>
> > > > > does
> > > > >
> > > > >> the service return to that? Why wouldn't the service send a CS
> > > in the
> > > > >> body of the GetMessage response to the client?
> > > > >>
> > > > >> Marc Goodner
> > > > >> Technical Diplomat
> > > > >> Microsoft Corporation
> > > > >> Tel: (425) 703-1903
> > > > >> Blog: http://spaces.msn.com/mrgoodner/
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >> Sent: Monday, April 24, 2006 1:11 AM
> > > > >> To: Marc Goodner
> > > > >> Cc: wsrx
> > > > >> Subject: Re: [ws-rx] i089 proposal
> > > > >>
> > > > >> Marc
> > > > >>
> > > > >> I use the words "Offered Sequence" informatively and 
> non-normatively.
> > > > >> This is most likely to be used with an offered sequence, but 
> isn't
> > > > >>
> > > > > tied
> > > > >
> > > > >> to that.
> > > > >>
> > > > >> As regards 4.2, this is there to satisfy the scenario where 
> you only
> > > > >> want reliable responses. I added this in for discussion 
> because I
> > > know
> > > > >>
> > > > >
> > > > >
> > > > >> that some members find this an important scenario. In that 
> case you
> > > > >>
> > > > > need
> > > > >
> > > > >> to be able to Offer a sequence without the overhead of 
> requesting
> > > one.
> > > > >>
> > > > >
> > > > >
> > > > >> It is related to the anonymous client because without a real 
> endpoint
> > > > >> the server cannot send a CS to the client so it relies on an 
> offer.
> > > > >>
> > > > >> Paul
> > > > >>
> > > > >> Marc Goodner wrote:
> > > > >>
> > > > >>
> > > > >>> Given 1 and 2, yes some text that clarified that not only is 
> this
> > > > >>> specific to RM but that a general solution would be 
> preferable would
> > > > >>>
> > > > >>>
> > > > >> be
> > > > >>
> > > > >>
> > > > >>> best.
> > > > >>>
> > > > >>> On 3 I suppose, I don't like seeing WS-A headers in the body 
> of a
> > > > >>> message though. Do you really even need the response for a 
> specific
> > > > >>> message? Why not return any responses or messages for that 
> sequence
> > > > >>>
> > > > >>>
> > > > >> that
> > > > >>
> > > > >>
> > > > >>> have not been acknowledged? And what are you talking about 
> when you
> > > > >>>
> > > > >>>
> > > > >> say
> > > > >>
> > > > >>
> > > > >>> this is tied to the offered sequence? What offered sequence? 
> I don't
> > > > >>>
> > > > >>>
> > > > >> see
> > > > >>
> > > > >>
> > > > >>> anything here that ties the use of your GetMessage proposal 
> to an
> > > > >>> offered sequence.
> > > > >>>
> > > > >>> I don't understand section 4.2 in your proposal at all. What 
> does
> > > > >>>
> > > > > this
> > > > >
> > > > >>> have to do with the rest of this proposal?
> > > > >>>
> > > > >>> Marc Goodner
> > > > >>> Technical Diplomat
> > > > >>> Microsoft Corporation
> > > > >>> Tel: (425) 703-1903
> > > > >>> Blog: http://spaces.msn.com/mrgoodner/
> > > > >>>
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >>> Sent: Thursday, April 20, 2006 1:57 AM
> > > > >>> To: Marc Goodner
> > > > >>> Cc: wsrx
> > > > >>> Subject: Re: [ws-rx] i089 proposal
> > > > >>>
> > > > >>> Marc
> > > > >>>
> > > > >>> 1) Yes - I completely aimed this to be a specific model for 
> RM. I
> > > > >>>
> > > > >>>
> > > > >> would
> > > > >>
> > > > >>
> > > > >>> be happy to include language that indicates that if a more 
> general
> > > > >>> purpose firewall crossing mechanism was in place this should 
> not be
> > > > >>> used.
> > > > >>> 2) The wsrm:Identifier is a required part of my proposal, and
> > > > >>> As a much lower technical detail, I do not believe your
> > > > proposal addresses one of the major issues
> > > > >>>
> > > > >> therefore
> > > > >>
> > > > >>
> > > > >>> this proposal is completely tied to the use of RM.
> > > > >>> 3) The suggestion of using messageNumber is interesting. The
> > > > >>>
> > > > >>>
> > > > >> motivation
> > > > >>
> > > > >>
> > > > >>> for using a message ID was that there may be situations where I
> > > > >>>
> > > > > really
> > > > >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>> want the response to a given message. We do not - so far - 
> have any
> > > > >>> concept of a response to a given RM messageID, so that 
> seemed like a
> > > > >>>
> > > > >>>
> > > > >> new
> > > > >> As a much lower technical detail, I do not believe your proposal
> > > > addresses one of the major issues
> > > > >>
> > > > >>> concept to me, whereas WS-A systems do keep track of 
> responses to
> > > > >>>
> > > > >>>
> > > > >> given
> > > > >>
> > > > >>
> > > > >>> messageIDs. But I'm not averse to your suggestion. However I 
> wish to
> > > > >>> make clear that in my proposal you MUST have both the 
> Identifier and
> > > > >>>
> > > > >>>
> > > > >> the
> > > > >>
> > > > >>
> > > > >>> messageID - so it is still very closely tied to the offered
> > > sequence.
> > > > >>>
> > > > >>> Paul
> > > > >>>
> > > > >>> Marc Goodner wrote:
> > > > >>>
> > > > >>> As a much lower technical detail, I do not believe your
> > > > proposal addresses one of the major issues
> > > > >>>
> > > > >>>> I hope that this is scoped to RM and not a general purpose 
> polling
> > > > >>>> mechanism. I assume that is your intent in that you use the
> > > > >>>> wsrm:Identifier and indicate that you see this being part 
> of the
> > > > >>>>
> > > > > core
> > > > >
> > > > >>>> spec. Still it seems like including language that indicates 
> that
> > > > >>>>
> > > > >>>>
> > > > >> would
> > > > >>
> > > > >>
> > > > >>>> be advised, particularly noting that if there were a general
> > > purpose
> > > > >>>> polling mechanism that it might be preferred over this one.
> > > > >>>>
> > > > >>>> So following from that why is MessageID in the GetMessage?
> > > Isn't the
> > > > >>>> identifier enough? If it isn't wouldn't the addition of
> > > > >>>> wsrm:MessageNumber do the trick?
> > > > >>>>
> > > > >>>> Marc Goodner
> > > > >>>> Technical Diplomat
> > > > >>>> Microsoft Corporation
> > > > >>>> Tel: (425) 703-1903
> > > > >>>> Blog: http://spaces.msn.com/mrgoodner/
> > > > >>>>
> > > > >>>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >>>> Sent: Thursday, April 06, 2006 12:40 PM
> > > > >>>> To: wsrx
> > > > >>>> Subject: [ws-rx] i089 proposal
> > > > >>>>
> > > > >>>> Folks
> > > > >>>>
> > > > >>>> At the F2F I took away an action to come up with a proposal 
> for
> > > i089
> > > > >>>>
> > > > >
> > > > >
> > > > >>>> before the call. I'm sorry its so close to the call.
> > > > >>>>
> > > > >>>> I've attached a proposal for review. This is a work in
> > > progress, but
> > > > >>>>
> > > > >>>>
> > > > >> I
> > > > >>
> > > > >>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> think it helps call out some of the issues involved around 
> i089.
> > > > >>>>
> > > > >>>> I think the most important questions for the TC are:
> > > > >>>>
> > > > >>>> (1) How does a customer/user use WSRM in a two-way scenario 
> if one
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>> side
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> is anonymous?
> > > > >>>> (2) Adding a "GetMessage" makes the protocol more 
> symmetric, but
> > > > >>>>
> > > > > also
> > > > >
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > > >>>> might overlap with a wider non-reliable solution to this
> > > problem. Is
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>> it
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> in the scope of this TC to add this?
> > > > >>>> (3) In the case we do add it, what criteria do we use to select
> > > > >>>>
> > > > > which
> > > > >
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > > >>>> message to request.
> > > > >>>> (4) Is this a generic solution (i.e. can the RMD request 
> messages
> > > > >>>>
> > > > >>>>
> > > > >> from
> > > > >>
> > > > >>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> the RMS in all cases) or special cased to anonURI scenarios?
> > > > >>>>
> > > > >>>> Paul
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > Paul Fremantle
> > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > >
> > > > http://feeds.feedburner.com/bloglines/pzf
> > > > paul@wso2.com
> > > >
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > >
> > >
> >
> > --
> >
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://feeds.feedburner.com/bloglines/pzf
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >



-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133