W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: Composibility problems with refps

From: Tom Rutt <tom@coastin.com>
Date: Mon, 22 Nov 2004 13:47:47 -0500
Message-ID: <41A23453.6070104@coastin.com>
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
CC: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org

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

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Monday, 22 November 2004 18:50:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT