[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: PROPOSAL PR013 (also covers some of PR012)
Actually rereading the issue text I believe this proposal completely closes issue 12. Paul Marc Goodner wrote: > What part of 12 does this cover and what else is needed for it? > > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Friday, November 17, 2006 6:58 AM > To: Doug Davis > Cc: Marc Goodner; ws-rx@lists.oasis-open.org > Subject: PROPOSAL PR013 (also covers some of PR012) > > At the end of this text > During creation of a Sequence the RM Source MAY specify the > WS-Addressing anonymous IRI as the > address of the AcksTo EPR for that Sequence. When the RM Source > specifies the WS-Addressing > anonymous IRI as the address of the AcksTo EPR, the RM Destination MUST > Transmit any > SequenceAcknowledgement headers for the created Sequence in a SOAP > envelope to be Transmitted > on the protocol binding-specific channel. Such a channel is provided by > the context of a Received > message containing a SOAP envelope that contains a Sequence header block > and/or an AckRequested > header block for that same Sequence identifier. > > > Add: > When the RM Destination receives an AckRequested header, and the ackTo > EPR for that sequence is the WS-Addressing anonymous IRI, the RM > Destination SHOULD respond on the protocol binding-specific channel > provided by the Received message containing the AckRequested header block. > > > Paul > > > > Doug Davis wrote: > >> Does this text in the spec cover it: >> >> During creation of a Sequence the RM Source MAY specify the >> WS-Addressing anonymous IRI as the >> address of the AcksTo EPR for that Sequence. When the RM Source >> specifies the WS-Addressing >> anonymous IRI as the address of the AcksTo EPR, the RM Destination >> MUST Transmit any >> SequenceAcknowledgement headers for the created Sequence in a SOAP >> envelope to be Transmitted >> on the protocol binding-specific channel. Such a channel is provided >> by the context of a Received >> message containing a SOAP envelope that contains a Sequence header >> block and/or an AckRequested >> header block for that same Sequence identifier. >> >> thanks >> -Doug >> __________________________________________________ >> STSM | Web Services Architect | IBM Software Group >> (919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com >> >> >> >> *Paul Fremantle <paul@wso2.com>* >> >> 11/16/2006 05:35 AM >> >> >> To >> Marc Goodner <mgoodner@microsoft.com> >> cc >> "ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org> >> Subject >> Re: [ws-rx] PR Issue 13 SequenceAcknowledgement protocol response for >> AcksTo = wsa:anonymous >> >> >> >> >> >> >> >> >> >> I'm not suggesting we define HTTP binding issues in our spec. I'm >> pondering the following: >> >> In the case where there is an anonymous AcksTo and an AckRequested, the >> RMD SHOULD respond with the SequenceAck on the backchannel of the >> request that carried the AckReq. >> >> Paul >> >> Marc Goodner wrote: >> >>> Paul, >>> >>> We can't describe HTTP binding issues in our spec, underlying >>> >> transports are simply out of scope. I don't have any issue with >> recommending they forward this issue to a group like WS-I's RSP WG >> where HTTP is in scope of their work. >> >>> -----Original Message----- >>> From: Paul Fremantle [mailto:paul@wso2.com] >>> Sent: Wednesday, November 15, 2006 12:08 AM >>> To: Marc Goodner >>> Cc: ws-rx@lists.oasis-open.org >>> Subject: Re: [ws-rx] PR Issue 13 SequenceAcknowledgement protocol >>> >> response for AcksTo = wsa:anonymous >> >>> Marc >>> >>> In the case of AckRequested over an anon HTTP connection, I believe the >>> RMD should respond directly. After all it doesn't know when the next >>> HTTP connection will come in to respond on. So I think they have a point >>> and we should state this. >>> >>> Paul >>> >>> Marc Goodner wrote: >>> >>> >>>> PR Issue 13, >>>> http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i013 , asks if >>>> an ack needs to be mapped to the original HTTP Response for the >>>> message. It also suggests that maybe wsaAnonymous is not an allowed >>>> value for acksTo and if so should be explicitly forbidden. >>>> >>>> I do not believe wsa:Anonymous should be barred from use in acksTo. I >>>> think the spec is pretty clear that the only barred value is wsa:None. >>>> >>>> I don't think we can address the mapping of an ack in this case to the >>>> HTTP layer as the underlying binding is out of our scope. In this case >>>> I think the specification already allows flexibility to send an ack on >>>> the HTTP response for the original request, or on a subsequent request >>>> including using AckRequested. >>>> >>>> If everyone else agrees I suggest we provide that feedback and close >>>> this issue with no action. >>>> >>>> >>>> >>> -- >>> 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 >> >> >> >> >> > > -- > 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]