- 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