[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] PR027 review
I agree. Re-reading my proposal, I think this whole issue is CNA against the main spec, and therefore should be retargeted to the MC spec. Paul Gilbert Pilz wrote: > One comment in line . . . > >> -----Original Message----- >> From: Paul Fremantle [mailto:paul@wso2.com] >> Sent: Thursday, January 04, 2007 1:12 PM >> To: ws-rx@lists.oasis-open.org >> Subject: [ws-rx] PR027 review >> >> PR027 was captured as an issue during the discussion of >> MakeConnection. >> >> The issue is this: >> >> Suppose the acksTo address is a distinct anonymous URI. >> >> There are two options: >> >> 1) the acksTo may be the WSA anon + reference parameters In >> this case acks can only get back either if the replyTo EPR >> matches the acksTo EPR. >> >> 2) the acksTo may be the RX anon + id >> In this case I think acks must be polled for using >> MakeConnection. Of course they may be piggybacked onto other >> messages destined for the same RX anon URI. This isn't clear >> from the spec. >> >> I think we need to address case #2 in the new MC spec document. >> >> I believe case #1 is already covered by the following text in the >> specification: >> Implementations MUST NOT use an endpoint reference in the >> AcksTo element that would prevent the sending of Sequence >> Acknowledgements back to the RM Source. >> >> I suggest we add the same text to AcksTo that we have for Endpoint: >> Implementations MAY use the WS-RM anonymous URI template and >> doing so implies that messages will be retrieved using a >> mechanism such as the MakeConnection message (see section 3.7). > > I think this opens up a interesting issue w/regards to the MC split; to what > extent and in which manner should the base spec refer to the MC spec and > vice versa? It seems to me that there are two ways we can go on this: > > 1.) The base spec obliquely refers to the MC spec in the manner you suggest > (i.e. using phrases such as "mechanisms such as . . ."). The MC spec, in > turn, fills in the gaps in the base spec. > > 2.) The base spec doesn't refer at all to the MC spec. The MC spec overrules > portions of the base spec. > > I think (2) is a preferable solution to (1). (1) inevitably leads to a base > spec which doesn't stand alone and which, when implemented and/or deployed > without MC support, has holes in it. To pick the most glaring example, what > should the base spec say about reliable responses to a non-addressable > client? If it says "it can be done but you have to use something like MC" > you've got a hole because you aren't defining what happens if you *don't* > have something like MC. > > - gp > >> I will let the monk^D^D^D^Deditors figure out where this goes >> in the new specs :-) >> >> Paul >> >> >> >> >> >> >> >> -- >> Paul Fremantle >> VP/Technology and Partnerships, WSO2 >> OASIS WS-RX TC Co-chair >> >> http://bloglines.com/blog/paulfremantle >> paul@wso2.com >> (646) 290 8050 >> >> "Oxygenating the Web Service Platform", www.wso2.com >> >> >> -- Paul Fremantle VP/Technology and Partnerships, WSO2 OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle paul@wso2.com (646) 290 8050 "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]