Saminda Aberuwan, Apache
Paul Fremantle, Apache
Patrik Johansson, Accenture
Hans Guldager Knudsen, Lenio
Christian Laang, XXXXX
Gert Sylvest, Avanade
Copyright© 2006 XXXXXXXX
This document describes a binding of SOAP [SOAP] into SMTP[SMTP] plus MIME[MIME]. Unlike previously published bindings, this binding ensures that the SOAP message is attached as a Base64[BASE64] encoded MIME attachment. This approach reduces the chance of mail scanners and SPAMS filters modifying the SOAP body.
This is an editor’s draft.
1.1 Notational Conventions
2. Use of MIME
3. Using WSDL
4. Using WS-Addressing
5. Request / Response semantics
7. Security Considerations
There is a published SMTP binding for SOAP 1.2[SOAP12SMTP]. However, this encodes the SOAP XML message as the textual body of the mail message. This binding enforces that the SOAP XML message is base64 encoded.
The aim of this binding is to allow SOAP systems to use the store and forward nature of SMTP to allow small businesses and other users to interact via SOAP without having to host publicly-accessible HTTP servers.
This binding is designed to work with MTOM[MTOM] attachments. In addition it is expected that this binding will successfully compose with SOAP-based standards such as WS-Security[WSSEC] and WS-ReliableMessaging[WSRM].
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC-2119].
SOAP payloads MUST to be packaged into a multipart MIME [MIME] message as an attachment. This provides a standard packaging layer that can take care of specifying transfer encodings, to cope with SMTP's 7bit nature. Also most MIME attachments are not modified by SPAM filters and anti-virus tools, minimizing problems.
The SMTP message MUST consist of a multipart MIME message.
The first part MUST be of type text/plain. It is RECOMMENDED that this part has no content.
The SOAP 1.2 payload MUST form the second part in the multi-part mime message, and MUST be Base64 encoded.
There MUST be only one mime part of content-type application/soap+xml
The SOAP 1.2 payload MUST be sent with the content type of "application/soap+xml".
The charset parameter MUST be used to specify the character encoding as per RFC2046 [RFC2046]. The action parameter SHOULD be used to specify the SOAP action.
Content-Type: application/soap+xml; charset=UTF-8;action="http://my.com/action"
A content transfer encoding of base64 MUST be used.
A content disposition MUST indicate that this is an attachment.
Many SOAP systems use the URL path (e.g. /soap/services/MyService) to route a message to a specific service. The Content-Description SHOULD be used to contain this path. This SHOULD be enclosed in quotes ("). This path is defined in section 3.
2.4 Other SMTP headers
The other SMTP headers can be used and will not change the outcome of the SOAP processing.
The URI http://xxxxxxxxxxxxx/yyy/zzz SHOULD be used to identify SMTP transports compliant with this specification in the transport attribute of the soap:binding element of a WSDL [WSDL] document.
There is a address of the SOAP service in the soap:address element of a WSDL document SHOULD be given by a URL based on the "mailto" URL scheme as defined by RFC 2368 [MAILTO]. In this case the following mailto syntax SHOULD be used.
In this case the mail client MAY add the SMTP header X-Service-Path with the value, but in addition the Content-Description SHOULD be set to this value.
The receiving agent SHOULD ignore the x-service-path header and rely on the Content-Description.
It is RECOMMENDED that WS-Addressing is used in this case, as this allows the SOAP message routing and service identification to occur independently of the transport.
In the case where WS-Addressing[WSA] headers are present in the SOAP message, the service SHOULD be identified using the X-Service-Path fragment of the mailto URL.
SOAP applications requiring request / response semantics will need to perform some sort of message correlation. This SHOULD be achieved via the standard Message-Id and In-Reply-To SMTP headers [SMTP]. The request will include a Message-Id header, and the associated response should include a In-Reply-To header that contains the Message-Id of the request, and a new Message-Id header.
The responder SHOULD also reflect the incoming subject header into the response, with no modifications.
A request destined for:
Content-Type: application/soap+xml; charset=UTF-8; action="http://test/action"
To our best knowledge, this introduces no new security considerations.
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", May 2000.
[SMTP] Klensin J., "Simple Mail Transfer Protocol" RFC2821, April 2001.
[RFC2119] Bradner S., "Key
words for use in RFCs to Indicate Requirement
Levels", RFC 2119,
[MIME] Freed N., Borenstein N. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" RFC2045, November 1996.
[WSDL] Christensen E., Curbera F., Meredith G., Weerawarana S. "Web Services Description Language (WSDL) 1.1", March 2001.
[MAILTO] Hoffman P., Masinter L., Zawinski J. "The mailto URL scheme" RFC2368, July 1998.
[RFC822] Crocker D.H., "Standard for the format of ARPA internet text messages" RFC822, August 1982.