SOAP Version 1.2 Email One-way Binding

W3C Note 26 June 2002

This version:
Latest version:
David Hull, TIBCO


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.

Status of this 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.

Notational Conventions

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.

Table of Contents

1 Introduction
2Binding Name
3 Supported Message Exchange Patterns
4 Request-Response Exchanges
4.1 Behaviour of Requesting SOAP Node
4.1.1 Init
4.1.2 Sending
4.1.3 Sending + Receiving
4.1.4 Success and Fail
4.2 Behaviour of Responding SOAP Node
4.2.1 Init
4.2.2 Receiving
4.2.3 Receiving + Sending
4.2.4 Success and Fail
5 Features Expressed External to the Message Envelope
5.1 Message Correlation Using msg-id
6 SOAP Email Examples
7 References

1 Introduction

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:

Table 1: Standard prefix mappings
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.

2 Binding Name

The binding described here is identified with the URI:

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.

3 Supported Message Exchange Patterns

An instance of a binding to Email[RFC2822] conforming to this binding specification MUST support the following message exchange pattern:

4 One-way Message Exchange Operation

The "http://www.w3.org/2002/06/soap/mep/one-way/" message pattern is described in ...

For binding instances conforming to this specification:

The remainder of this section consists of descriptions of the MEP properties, and their particular relation to RFC 2822.

4.1 Mapping of MEP properties to email fields
In sending and receiving SOAP messages, the properties of the exchange context correspond to the content of an email message as follows:

Table 2: Email Fields
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.
4.2 Behaviour of Sending SOAP Node

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.

4.3 Behaviour of Receiving SOAP Nodes

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.

5. Features Expressed External to the Message Envelope

This section is identical to the original

6. SOAP Email Examples


7. References

This section is identical to the original, except for references to the MEP in question