Feature: MIME Composite 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

Generation of a binding for internet email leads inevitably into a consideration of the requirements of internet email, especially including the typing of messages using MIME. This feature attempts to abstract the complexity of composite MIME messages (types multipart/* and message/*) into a feature set which may then be bound as appropriate not only for internet email, but for other protocols as well.

The design of this feature is intended to make it suitable for reuse by other protocol and application bindings. In particular, it may be appropriate to make reference to this feature within the Soap with Attachments specification.

Contents

Status

Motivation

Table of Contents

Dependencies

Definitions

Description

Interactions with Other Features

Implementation as a Module

Security Consideration

References

Dependencies

Implementation of the mime-composite feature requires implementation of the mime-content feature, because the former merely extends the latter.

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
mimecomphttp://www.tibco.com/xmlns/soap/mime-composite/

The URL for this feature (not required as with MEPs, but certainly useful) is http://tibco.com/soap/mime-composite/. Properties are defined within this namespace. The "common" namespace prefix (used throughout this document) is mimecomp. This feature describes two additional optional properties implied in mime-content, and extends the value space of mime content's content-type property.

Table 2: Properties for the MIME Composite Feature
Name Type Constraints
mimecomp:content-type enumerationRequired; extended from mime-content
mimecomp:content-id xs:string Optional; unique within document
mimecomp:content-locationxs:anyURI Optional
mimecomp:current-part message partRequired; emergent
mimecomp:content-type
The mime-composite feature's major contribution is an extension of the value space of the mimecont:content-type property. This feature permits the use of the composite types, message and multipart (and all their subtypes). This permits the creation of multipart and embedded messages; the usual semantics apply. Note that a binding (protocol, MEP, module, or application) must therefore specify how the property is bound for the message as a whole, but also how it is bound to each message part. Each message part must have at least a content-type property bound, and generally must bind other properties as well.
mimecomp:content-id
The mime-composite feature also specifies, optionally, the use of part identifiers, bound through the content-id property. A content id is a unique string within the scope of the message as a whole. It may have further restrictions placed on it by the protocol, application, MEP, or module binding. Content IDs should be created at message creation time, and remain unchanged thereafter; they may be used as references within certain types of message.
mimecomp:content-location
The content-location property is basically similar to the content-id property, except that it expects that there are internal references already in existence in one or more parts of the message, and it allows each part of the message to adopt a sort of alias in order for it to correspond to the references. For instance, an HTML page may contain relative URIs pointing to images or scripts; a message may bundle all of these pieces, and apply content-locations to each in order to maintain the existing relationships. As with most MIME-related properties, the most common implementation binds to MIME headers in a compliant protocol, but this need not be the case.
mimecomp:current-part
The current-part property refers to a MIME-boundaried portion of a message, containing its headers (which may be bound to properties) and its body content. It is similar, in many ways, to the context:CurrentMessage super-property, and in fact may replace that for processing purposes (the SOAP with attachments model anticipates a single SOAP message plus supporting materials; while current-part is the SOAP message, it corresponds to the context:CurrentMessage property, in effect). Protocol bindings should bind this property to each part in turn, as each is processed. There is no mimecomp:current-part for transmission; it is exclusively a local property, emergent from processing.

Description

The mime-composite feature provides support for composite messages (typically multipart/*, although message/* is possible as well), which effectively broadens the requirements upon implementors to support many more possible types of message (since SOAP requires that a single-part SOAP message be assigned the type application/soap+xml). The feature also defines the properties (almost always associated with headers of a part in a MIME-compliant protocol) which allow identification and cross-reference of the various related parts of a message.

The mimecomp:current-part property is valid only during encoding (creation) of a message and decoding (receipt/processing) of a message. The application is expected to reset this property as each message part is processed. While an attachment is being processed, many of the properties associated with context:CurrentMessage may not be accessible (this is true largely only when the SOAP message part has not been processed already, but in some cases may be true when processing of the SOAP part is complete).

Each message part should contain its own mimecont:content-type and mimecont:transfer-encoding properties, as well as optional mimecomp:content-id or mimecomp:content-location properties. These properties are almost invariably bound to the MIME headers associated with each part.

It might be useful for us to define a mimecomp:container property. No?

Interactions with Other Features

The mime-composite feature extends the value space of the content-type property of the mime-content feature. Implementation of the MIME composite feature depends upon MIME content; support for the composite feature must always include support for the content feature.

Apart from extending the mime-content feature, the MIME composite feature may possibly be referenced as a possible implementation approach for Soap with Attachments.

The feature is otherwise independent of other features. It describes the content of a message which contains complex structure.

Implementation as a Module

It is strongly recommended that use of this feature via its module implementation be forbidden when bound to a MIME-compliant protocol. In fact, it is generally recommended that if the protocol bound to is not MIME compliant, the MIME composite feature not be implemented at all.

It is theoretically possible to create a set of SOAP headers appropriate for the container, and for each of the contained parts in a composite message. The problem is tractable, but difficult. This specification makes no attempt to define such a binding.

Security Considerations

Decoding of MIME content carries potential security implications. Implementors should check existing literature on potential weaknesses, and should in general not code automatic execution of delivered content into SOAP applications (although execution of instructions found in the SOAP message is an inescapable reality of SOAP).

References


Amelia A Lewis
Last modified: Fri Oct 11 16:29:36 EDT 2002