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, 15 November 2004 19:10:15 UTC