Feature: MIME Content for Simple Messages

Status

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.

Motivation

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.

Contents

Status

Motivation

Table of Contents

Dependencies

Definitions

Description

Interactions with Other Features

Implementation as a Module

Security Considerations

Additional Notes

References

Dependencies

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.

Definitions

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.

Table 1: Feature Namespace and Prefix
PrefixNamespace
mimeconthttp://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.

Table 2: Properties for the MIME Content Feature
Name Type Constraints
mimecont:mime-version xs:string 1.0 if not specified
mimecont:content-type enumerationRequired; see RFC; restricted
mimecont:transfer-encodingenumerationRequired
mimecont:* xs:any various
mimecont:mime-version
Although MIME-compliant protocols must specify the MIME-Version header, the mime content feature does not require that the property be bound by a MEP, module, protocol or application. If the property is not bound, it defaults to 1.0 (currently the only version of MIME). The property is defined for future compatibility: later versions of MIME may change meanings, so the version describes which suite of properties is defined. If the property is bound, it must be set at message creation, and carried with the message.
mimecont:content-type
The mime content feature requires that each message be assigned a message type. Because the content feature does not discuss issues of composite messages, the composite types (message and multipart) are not legal. The only legal types are text, audio, application, model, and image. Any subtype may be specified. The message type must be set at message creation, must be carried with the message, and may not be changed (unless the message is transformed, but that effectively means the creation of a new message). MEPs, modules, protocols, and applications may bind the property as they wish, but it is most commonly bound to a MIME header in a protocol binding for a MIME-compliant protocol. Some bindings may set a universal default (for instance, application/soap+xml) so that the property is not required to be bound into the message at all (except implicitly).
mimecont:transfer-encoding
The mime content feature requires that each message be assigned a transfer encoding, which is one of the MIME-defined set: 7bit, 8bit, binary, base64, and quoted-printable. When used with XML, anything other than binary or base64 is discouraged. As with content type, the content transfer encoding must be set at message creation, carried with the message, and left unchanged. Bindings are typically to the Content-transfer-encoding MIME header, but need not be (for instance, HTTP changes the default for a missing header (and missing is the normal case for HTTP) from 7bit to binary).
mimecont:*
The MIME specifications, and several of their extensions, define a number of additional headers, many of which can be mapped to properties. This version of this specification does not discuss these properties further, although later versions may provide better specification.

Description

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.

Interactions with Other Features

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).

Implementation as a Module

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>

Security Considerations

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.

Additional Notes

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.

References


Amelia A Lewis
Last modified: Fri Oct 11 12:52:23 EDT 2002