Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document is meant to supplement the existing
SOAP email binding to implement the SOAP one-way MEP. In
practice, the material here unique to the one-way MEP binding would be
incorporated into the existing document.
This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by the Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.
This document is the result of the Transport Binding Task Force(TBTF), which is part of the XML Protocol WG.
A list of current W3C technical documents can be found at the Technical Reports page.
The motivation for this document is to illustrate the SOAP 1.2 Protocol Binding Framework and the creation of a protocol binding for the proposed SOAP one-way MEP. This binding is meant to validate the one-way MEP for completeness and usability. Please note that this document is a non-normative description of an Email Binding.
It is not the responsibility of this SOAP binding to mandate a specific email infrastructure, therefore specific email infrastructure protocol commands (such as SMTP, POP3, etc) are not covered in this binding document. The underlying email infrastructure and the associated commands of specific email clients and servers along the message path are outside the scope of this email binding.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [KEYWORDS].
Namespace URIs of the general form "some-URI" represent some application-dependent or context-dependent URI as defined in RFC2396 [URI]. The namespace prefixes "SOAP-ENV" and "ds" used in this document are associated with the namespaces "http://schemas.xmlsoap.org/soap/envelope/" and "http://www.w3.org/2000/09/xmldsig#", respectively.
This SOAP binding specification adheres to the SOAP Protocol Binding Framework (see SOAP Protocol Binding Framework), and as such uses abstract properties as a descriptive tool for defining the functionality of certain features.
Properties are named with XML qualified names (QNames). Property values are determined by the Schema type of the property, as defined in the specification which introduces the property. The following tables lists the standard prefix mappings which we assume to hold throughout this specification:
| Prefix | Namespace |
|---|---|
| context | http://www.example.org/2001/12/soap/bindingFramework/ExchangeContext/ |
| mep | http://www.example.org/2001/12/soap/mep/ |
| fail | http://www.example.org/2001/12/soap/mep/FailureReasons/ |
| reqresp | http://www.example.org/2001/12/soap/mep/request-response/ |
Email applications MUST use the media type "application/soap+xml" according to [soap-media-type] when including SOAP 1.2 messages in Email exchanges. See [soap-media-type] for parameters defined by this media type and their recommended use.
The binding described here is identified with the URI:
http://www.example.org/2002/02/soap/bindings/Email/one-way
This binding is provided as an example binding when using Email and the standard Internet Message Format described in rfc2822. Unlike HTTP, Email does not inherently provide a request/response Message Exchange Operation. An Email message meant to be a response to the original request will be sent back to the original sender. A means of correlating the original request to the resulting response will be descibed as a binding feature.
An instance of a binding to Email[RFC2822] conforming to this binding specification MUST support the following message exchange pattern:
http://www.example.org/2001/12/soap/mep/one-way/
The "http://www.w3.org/2002/06/soap/mep/one-way/" message pattern is described in ...
For binding instances conforming to this specification:
A SOAP Node instantiated at an email protocol interface may take
on the role (i.e. the property one-way:Role)
of SendingSOAPNode.
A SOAP Node instantiated at an email protocol interface may take
on the role (ie. the property one-way:Role)
of ReceivingSOAPNode.
The remainder of this section consists of descriptions of the
MEP properties, and their particular relation to RFC 2822.
| Field Descriptions | |
| Originator and Destination Fields | "From:" sender-uri CRLF "To:" receiver-uri CRLF "Message-ID:" correlation:requestMessageID CRLF |
| Sender URI | The value of the URI carried in the one-way:ImmediateSender
property of the message
exchange context. |
| Receiver URI | The value of the URI carried in the one-way:ImmediateDestination
property of the transport
message exchange context. |
| Correlation Request Message ID | The Request email msg-id value is automatically generated at
the requesting node's email interface. The correlation feature
correlation:requestMessageID is described in Section
5.1. |
| Content-Type (MIME) header | "application/soap+xml" (see Introduction) |
| Email message body | XML 1.0 serialisation of the SOAP message XML Infoset carried
in the one-way:OutboundMessage property (or one-way:InboundMessage
property, for a receiving node) of the transport message
exchange context. |
The overall flow of the behaviour of a Requesting SOAP Node
follows the description contained in ...
In each instance of the MEP, the sending node formulates an email
message from the properties of the exchange context according to table
2 above.
In each instance of the one-way MEP, each receiving SOAP node whose email interface receives the message sent populates the properties of the exchange context from the content of the email message as described in table 2 above. As per the normal rules of email, there may be zero or more receivers for any particular message.