- From: David Hull <dmh@tibco.com>
- Date: Thu, 01 Dec 2005 12:51:30 -0500
- To: public-ws-addressing-comments@w3.org
- Message-id: <438F3822.7080306@tibco.com>
*Description:* Currently, we constrain the HTTP SOAPAction request header to be either identical to the [action] MAP (and the wsa:Action) header or to be (effectively) blank. This is a narrow ruling, however. We do not place any constraints on other transport-level metadata that may overlap in function with MAPs, for example, the from:, to: reply-to:, message-id: and in-reply-to: headers in an email binding, nor do we even provide guidance for such a situation. Note that the case of reply-to: and similar constructs is a bit special, in that they will likely be used in the definition of the SOAP request-response MEP, which section 3.5 explicitly links to the anonymous URI. Aside from this, the general question is: "If the transport provides a from: header or similar construct, must this be identical to (or a default for) the [source endpoint] MAP?", and analogously for message-id: and [message id], in-reply-to: and [relationship] (bearing in mind that [relationship] is more general than in-reply-to:). *Justification:* In the absence of explicit statements, implementations may differ as to how the transport-level constructs relate to the MAPs. For example, the message-id: may be construed as overriding the wsa:MessageId header (and thus the [message id] MAP), or vice versa, or a mismatch may be treated as an error, or the message-id: may be taken as a default for [message id]. *Target:* SOAP binding *Proposal:* 1. Do nothing and expect authors of bindings to clarify the semantics. 2. Do nothing normative, but non-normatively call out the issue as one of concern to authors of transport bindings. 3. Do nothing normative, but call out the issue and specifically RECOMMEND a particular approach. 4. Normatively specify rules for transport-level metadata analogous to WSA MAPs (but let authors of bindings determine what information is analogous in what ways). Personally, I would prefer (2) or (3).
Received on Thursday, 1 December 2005 17:51:54 UTC