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.
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.
Interactions with Other Features
Implementation of the mime-composite feature requires implementation of the mime-content feature, because the former merely extends the latter.
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 |
---|---|
mimecomp | http://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.
Name | Type | Constraints |
---|---|---|
mimecomp:content-type | enumeration | Required; extended from mime-content |
mimecomp:content-id | xs:string | Optional; unique within document |
mimecomp:content-location | xs:anyURI | Optional |
mimecomp:current-part | message part | Required; emergent |
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?
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.
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.
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).