OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] PR027 review


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
> 
> 
> 

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]