- From: David Hull <dmh@tibco.com>
- Date: Thu, 05 May 2005 17:04:37 -0400
- To: public-ws-addressing-comments@w3.org
- Message-id: <427A8A65.9020801@tibco.com>
Section 3.1 of the core states that "These properties [i.e., MAPs] are
immutable and not intended to be modified along a message path." The
SOAP binding amplifies this by saying first (in section 3.2) "When
sending a message each property is represented using the appropriate
element information item as a SOAP header block." (i.e., properties must
be represented as header blocks), and (in section 6.1) "To avoid
breaking signatures, intermediaries MUST NOT change the XML
representation of WS-Addressing headers. Specifically, intermediaries
MUST NOT remove XML content that explicitly indicates otherwise-implied
content, and intermediaries MUST NOT insert XML content to make implied
values explicit." (i.e., the header blocks must not be changed in transit).
However, the SOAP binding also says (in section 3.2), "Note that the
message addressing properties gathered by an intermediary when receiving
a SOAP message do not necessarily get replayed as MAPs when resending
the message along the message path." and also (in section 2.2) that "A
binding that supports this feature MUST provide a means to transmit the
properties listed above with a message and to reconstitute their values
on receipt of a message." This last statement appears to imply that
there are means other than simply putting the properties in the envelope
as headers.
Several questions arise:
* In what scenarios would " message addressing properties gathered
by an intermediary ... not necessarily get replayed ..."?
* Is a binding required to put MAPs on the wire as headers, or may
it use transport-specific representations (e.g., any routing
headers used by an underlying transport) without echoing them as
SOAP headers?
* Is an intermediary forbidden from changing headers in all
circumstances, or only when those headers are signed?
The spec seems unclear, in that there are statements that at least
appear to conflict. Unfortunately, I can't propose a clarification
without better knowing the intent.
Received on Thursday, 5 May 2005 21:04:46 UTC