This proposal is intended to meet the requirements for a SOAP feature, as described in section 3.1 and 3.1.1 of the SOAP 1.2 Specification, with the exception that the description is not necessarily limited to "between two adjacent SOAP nodes," merely "between adjacent SOAP nodes." The document has no formal status whatsoever, within W3C and its working groups, or within TIBCO.
This feature defines the properties necessary for a binding or module to permit identification of content via the internet standard MIME format. It was developed in order to provide a substrate for an example binding. This feature does not address multipart (composite) MIME messages; that is left to the mime-composite feature (which extends this feature).
This feature description is intended to be general enough that it may be used with other bindings than that which prompted its creation. Its primary functionality is to allow the typing of messages. In SOAP, this typing is typically hard-coded (application/soap+xml), if composite messages are not considered.
Interactions with Other Features
The mime-content feature does not depend on any other features. It describes the content of messages in a relatively standardized fashion, which modules, MEPs, and bindings can then specify in greater detail.
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 RFC2119.
Prefix | Namespace |
---|---|
mimecont | http://www.tibco.com/xmlns/soap/mime-content/ |
The URL for this feature (not required as with MEPs, but certainly useful) is http://tibco.com/soap/mime-content/. Properties are defined within this namespace. The "common" namespace prefix (used throughout this document) is mimecont. This feature establishes two required and one optional properties which implementing bindings or modules must bind, and processors must handle.
Name | Type | Constraints |
---|---|---|
mimecont:mime-version | xs:string | 1.0 if not specified |
mimecont:content-type | enumeration | Required; see RFC; restricted |
mimecont:transfer-encoding | enumeration | Required |
mimecont:* | xs:any | various |
Properties defined by the mime-content feature should always be assigned at message creation, and should not be changed in transmission (with rare exceptions; see next paragraph). The feature definition permits the mimecont:mime-version property to be defaulted (because there is currently only one version available; introduction of another version would force users of the later version to specify the property, and would treat a missing property as 1.0). In SOAP, the mimecont:content-type property SHOULD always be set to application/soap+xml. The content-type property should never change in transmission.
Servers (not SOAP nodes, but ordinary servers) for MIME-compliant protocols have a little leeway in transcoding messages received. For instance, it may be that a message transmitted with Content-transfer-encoding: 8bit to start can hit a hop, for which the server at the other end does not support the 8BITMIME SMTP extension (or the equivalent for other protocols). It is permitted for the sending server to transcode the message, from 8bit to base64, for instance (or to quoted-printable, etc.). Therefore, although the mimecont:transfer-encoding property SHOULD NOT change, it may, if only because servers in the path may not be conforming SOAP nodes. SOAP nodes recognizing the MIME feature MUST be able to handle both 8bit and 7bit transmission and reception.
In its current state, the mime-content feature acknowledges the existence of additional MIME properties which may need to be bound in some protocol or application. However, at present these are entirely underspecified, so interoperable use may not be possible. Further work is needed in this area. It may be that these other headers should properly be assigned to a different feature altogether.
The mime-content feature requires no other features for its implementation. At least one other feature, mime-composite extends the feature (by extending the value space of the content-type property).
It is strongly recommended that bindings to MIME-compliant protocols forbid the use of the mime-content feature as a module. Permitting it raises questions of synchronization (between the SOAP headers and the protocol headers), and potentially robs the protocol processing agents of information that they need for proper operation.
Bindings to protocols that are not MIME-compliant, especially if the protocol bound does not have obvious equivalents to the MIME headers in format or structure, may wish to use a module-based implementation. It is recommended that the header set mustUnderstand true.
<soap-env:Header> <mimecont:mime-content> <mimecont:version>xs:string</mimecont:version>? <mimecont:content-type>xs:string</mimecont:content-type> <mimecont:transfer-encoding>xs:string</mimecont:transfer-encoding> <mimecont:ANY>xs:string</mimecont:ANY>* </mimecont:mime-content> </soap-env:Header>
The mime-content feature poses no new security considerations. Client software capable of handling MIME may have to be carefully coded, in order to prevent attempted attacks (for instance, the application/postscript type is naively treated as a display format, but the language is turing-complete and thus capable of extensive abuse by malicious attackers). These considerations are a consequence of the use of MIME, however, and given that the usual and primary MIME type for SOAP is application/soap+xml, they have little relevance. However, implementors attempting more general solutions should check the literature for known weaknesses and code defensively for those cases.
The usual binding of the mime-content feature is to a protocol that is MIME-compliant, although it may also be bound to protocols that are MIME-compatible but not compliant (such as HTTP). Typical usage is to bind to the existing MIME headers. Effectively, then, this feature simply promotes MIME headers from the protocol into SOAP visibility.
One of the most commonly encountered issues for MIME-compliant protocols is that they are fundamentally seven-bit clean. This is awkward, but unavoidable. The original (and subsequent) specification(s) targeted internet email specifically, and to the present, internet email is not reliably eight bit clean. As a result, there are a number of issues associated with encoding of material that is not inherently 7bit. XML, which is defined to support the full Unicode character set, brings these issues to the fore.
Applications using XML as a transfer format cannot define the format as text, because the MIME definition of text is only seven-bit clean. It is possible to encode the text, but quoted-printable is extremely ugly, and 8bit (which might otherwise be preferred) is unreliable over many protocols. SOAP must therefore use different character sets (that can be effectively encoded in seven bits), or must use the application/soap+xml type (the solution selected), which effectively denies one of the principles of XML, that it is a text encoding. Over some MIME-compatible protocols (notably HTTP), the problem is substantially reduced. However, service implementations should be careful of the assumptions made for encoding of XML to travel over MIME-compliant protocols. Solutions such as base64, which inflate the already verbose XML format, may be the only safe handling.