- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 22 Nov 2004 11:03:40 -0800
- To: tom@coastin.com
- CC: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org
I agree that would indeed solve the problem -- either refp specific header(s) or the use of [to] property. -Anish -- Tom Rutt wrote: > > As Glen has suggested before, encapsulating the ref parms and ref props > in a ws-addressing specific header element would allow arbitrary > qnames for the ref props and ref parms, without confusion. > > Tom Rutt > > Anish Karmarkar wrote: > >> >> Yes. >> Or in the context of SOAP, composability with any specification that >> uses SOAP header(s) as a mechanism to convey information. >> >> -Anish >> -- >> >> Jonathan Marsh wrote: >> >>> Specifically, you're worried about the case where the reference >>> properties and reference parameters are in a namespace used by the >>> reliability, security, etc. mechanisms, right? >>> >>> >>>> -----Original Message----- >>>> From: public-ws-addressing-request@w3.org [mailto:public-ws- >>>> addressing-request@w3.org] On Behalf Of Anish Karmarkar >>>> Sent: Monday, November 15, 2004 11:10 AM >>>> To: public-ws-addressing@w3.org >>>> Subject: Composibility problems with refps >>>> >>>> >>>> All, >>>> >>>> During last week's concall discussion of issue i008 I took an action >>>> to >>>> explain the composibility problem with refps in an email. This email >>>> fulfills that action. >>>> >>>> WS-Addressing [1] Submission includes [reference properties] and >>>> [reference parameters] in the info models for EPR. These refps are >>>> opaque to the consumer. In the SOAP binding of EPR, the refps are >>>> bound >>>> as individual SOAP header blocks. I.e., a consumer of a EPR using SOAP >>>> is required to copy the refps as individual SOAP header blocks without >>>> understanding what the blocks mean or do. >>>> >>>> Typically SOAP header blocks are part of a SOAP module and express >>>> certain functionality. For example, WSS, WS-Reliability, >>>> WS-ReliableMessaging, WS-C, WS-T WS-Context etc, specify header blocks >>>> that have a particular meaning that is conveyed from the sender to the >>>> receiver. Specifications in the realm of Web services are designed to >>>> be >>>> composible with other specs. For example, WS-Context can be composed >>>> with WS-Reliability and WSS. >>>> >>>> A consuming application that dereferences an EPR that contains refps >>>> may >>>> have some policies in place wrt to reliability, security, >>>> coordination, >>>> transaction, privacy etc. Given that refps may contains any XML and >>>> these refps are bound as SOAP header blocks, refps can potentially >>>> interfere with composibility of WS-Addressing with other WS-* specs >>>> that >>>> the consumer may be using. The opacity of the refps prevents the >>>> consumer from making any inferences about the refps in an EPR. >>>> >>>> This issue is slightly different from the security of EPRs -- which >>>> *may* potentially be resolved by requiring the minter of the EPR to >>>> sign >>>> the EPR. >>>> >>>> HTH to clarify the issue. >>>> >>>> -Anish >>>> -- >>>> >>>> >>>> >>>> [1] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ >>>> >>> >>> >>> >> >
Received on Monday, 22 November 2004 19:04:25 UTC