New CR Issue: Relation of SOAP Headers to transport-level headers

*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