SOAP Message Transmission Optimization Mechanism

1. Introduction

The first part of this document (2. Abstract Transmission Optimization Feature) describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message by selectively re-encoding portions of the message, while still presenting an XML Infoset to the SOAP application.

This Abstract Transmission Optimization Feature is intended to be implemented by SOAP bindings, however nothing precludes implementation as a SOAP module.

Unlike SOAP itself, which is defined in terms of XML Infosets [XMLInfoset], this feature models message envelopes using the XQuery 1.0 and XPath 2.0 Data Model [XML Query Data Model], which is a typed superset of the Infoset. This feature uses type information only for optimization purposes; it does not provide for reconstruction of type information at receivers, except as necessary to support optimization. Nonetheless, use of the data model in this specification facilitates optimized transmission of query results through SOAP, and should provide a useful foundation if, for example, digital signature canonicalizations were to be developed for data model instances. Use of the data model here should also facilitate the work of those who may wish to develop features to provide for optimized transmission of the full typed model: the changes needed to this specification should be straightforward, and the optimizations provided herein should be easy to generalize for such use.

The usage of the Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path, providing no mandatory convention for optimization of SOAP transmission through intermediaries. The feature does provide optional means by which binding implementations MAY choose to facilitate the efficient passthrough of optimized data contained within headers or bodies relayed by an intermediary (see 2.4.4 Binding Optimizations at Intermediaries). Additional specifications might also be written to provide for other optimized multi-hop capabilities, perhaps building on the mechanisms provided herein.

The second part (3. Inclusion Mechanism) describes an Inclusion Mechanism implementing part of the Abstract Transmission Optimization Feature in a binding-independant way. The third part (4. HTTP Transmission Optimization Feature) uses this Inclusion Mechanism for implementing the Abstract Transmission Optimization Feature for an HTTP binding.

The second part (4. HTTP Transmission Optimization Feature) describes an implementation of the Abstract Transmission Optimization Feature for an HTTP binding using the MIFFY format (ref?).

This document represents a transmission optimization mechanism which was inspired by a similar mechanism in the PASWA document (see [PASWA]). The WG plans to work later on the other parts of that document (assigning media types to binary data in XML infosets and including representations of Web resources in SOAP messages) and to publish other drafts which will include such mechanisms.

1.1 Notational Conventions

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

This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see XML Infoset [XML InfoSet]).

Table 1: Prefixes and Namespaces used in this specification.
Prefix	Namespace	Notes
dm	"???"	Consistent with [XML Query Data Model], this prefix is used to qualify accessor names in the XQuery 1.0 and XPath 2.0 Data Model. Apparently, no URI has been reserved to correspond to this prefix.
env	"http://www.w3.org/2003/05/soap-envelope"	A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the "http://www.w3.org/2003/05/soap-envelope" namespace can be found at http://www.w3.org/2003/05/soap-envelope.
xbinc	"http://www.w3.org/2003/06/soap/features/binary-inclusion"	The namespace of the 3. Inclusion Mechanism.
xdt	"http://www.w3.org/2003/05/xpath-datatypes"	The namespace of the XPath data types.
xs	"http://www.w3.org/2001/XMLSchema"	The namespace of XML Schema data types [XML Schema Part 2].

Editorial note: HR
Check which namespaces are still used in the specification.

Editorial note: NRM
Need biblio reference for XPath Data Types.

1.2 Relation to other specifications

This specification has currently no well-defined relation with the [SOAP 1.2 Attachment Feature] specification. However, it may be expected that this specification will supersede the [SOAP 1.2 Attachment Feature] specification once this specification has reached a stable state.

Even if this specification does not target specifically attachments to a SOAP message, it is expected that it will fulfill all attachment feature requirements described in [SOAP Attachment Requirements].

The implementation of the abstract feature as a binding feature for an HTTP binding is intended to enhance the SOAP HTTP binding described in [SOAP Part 2] SOAP HTTP Binding or an updated version of it.

See 1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0 Data Model for a discussion of the XML Infoset ([XML InfoSet]), and the XQuery 1.0 and XPath 2.0 Data Model ([XML Query Data Model]), and their use by this specification.

This document has been produced in conjunction with the development of requirements, embodied in the requirements document [SOAP Attachment Requirements]. The requirements document is a work in progress. No reconciliation of this document and the requirements document has been done for this publication. It is expected that this document and the requirements document will iteratively evolve over time.

1.2.1 Use of the Infoset and the XQuery 1.0 and XPath 2.0 Data Model

1.2.2 Relationship to the SOAP Processing model

This feature makes no changes to the SOAP processing model. Although type information is used to optimize transmission of SOAP envelopes, that type information in no way affects the processing of messages once received. As described in A. Mapping between Infosets and Data Models, there is in all cases an untyped Infoset corresponding to each transmitted and received envelope data model. The data models transmitted MUST in all cases correspond to legal SOAP envelope Infosets, and SOAP processing MUST be performed on received Infosets in the manner prescribed by the SOAP Recommendation.

Editorial note: HR
This section should probably be conserved, however it will need to be revisited and moved to another location.

2. Abstract Transmission Optimization Feature

2.1 Introduction

The Abstract Transmission Optimization Feature enables SOAP bindings to optimize the transmission and/or wire format of a SOAP message by selectively re-encoding portions of the message, whilst still presenting an XML Infoset to the SOAP application.

The Abstract Transmission Optimization Feature also enables SOAP applications to provide hints about what part of a SOAP message could be re-encoded in an efficient way. However, it is up to the implementation to decide if and how it will optimize the transmission of a given SOAP message.

2.2 Abstract Transmission Optimization Feature Name

This Abstract Transmission Optimization Feature is identified by the URI:

"http://www.w3.org/2003/06/soap/features/abstract-optimization".

2.3 Abstract Transmission Optimization Feature Properties

Editorial note: HR
As the ATOF has no longer any property, this section has been deleted.

2.4 Abstract Transmission Optimization Feature Processing

2.4.1 Sending a message

To send a SOAP message using the Abstract Transmission Optimization Feature, an application MUST enable the Abstract Transmission Optimization Feature. In addition it SHOULD define the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property.

When sending a SOAP message, the SOAP processor implementing the Abstract Transmission Optimization Feature MUST check whether this Feature is enabled or not. The Abstract Transmission Optimization Feature can be enabled by the application using the SOAP processor, by the configuration of the SOAP processor or by any other means.

If the Abstract Transmission Optimization Feature is enabled, the SOAP processor SHOULD use any available implementation of the Feature for sending the SOAP message. Note that the implementations of the Feature available can depend on other constraints set for the sending the SOAP message.

If the Abstract Transmission Optimization Feature is not enabled, the SOAP processor MUST not use any implementation of the Feature for sending the SOAP message.

When sending a SOAP message with the Abstract Transmission Optimization Feature enabled, a SOAP node using a binding implementing the Abstract Transmission Optimization Feature SHOULD optimize the transmission of all the SOAP message element nodes listed in the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property. The means of optimization is at the discretion of the binding. The fact that optimization candidates are known to be of dm:type=xs:base64binary and in canonical form implies that transmission of the dm:typed-value is sufficient to enable reconstruction of the required dm:string-value at the receiving node. Bindings MAY use such means of optimization if desired.

In addition, the SOAP node binding MAY optimize the transmission of other SOAP message element nodes not listed in the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property. In particular, if the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property is not defined or if it has an empty value, the SOAP node binding MAY optimize the transmission of any SOAP message element node(s) which have a dm:type of xs:base64binary and which are known to be in canonical form.

Editorial note: HR
Do we allow the optimization of the `Envelope` , `Header` , `Body` element information items, or of a full Header Block?

Editorial note: HR
If the binding used does not implement the Abstract Transmission Optimization Feature there are several options which can be followed: fault; send the message ignoring the request for using the Abstract Optimization Feature; send the message including the request for using the Abstract Transmission Optimization Feature (allows an intermediary implementing it to use its implementation).

2.4.2 Receiving a message

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node MUST fault if it does not support the implementation used or the Abstract Transmission Optimization Feature.

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node binding MUST reconstruct the transmitted data model, with the following exceptions:

The dm:type of any or all received data model nodes may be set as indeterminate, using the mechanisms of dm:type.
For any such nodes, the dm:typed-value must be adjusted accordingly, E.g. to return the same characters as dm:string-value for elements and attributes of simple type (see dm:typed-value).

The receiving node MUST reconstruct from the data model an Envelope Infoset, as described in A.2 Infoset Mapping at Receiving Nodes; the receiving node MUST then perform SOAP processing on the reconstructed Infoset.

A SOAP node receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature MUST reconstruct the Envelope Infoset as specified by the implementation of the Feature. The receiving node MUST then perform SOAP processing on the reconstructed Infoset.

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node binding MUST enable the Abstract Transmission Optimization Feature. In addition, the SOAP node binding SHOULD/MAY set the value of the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property to reflect the SOAP message parts whose transmission was optimized in the incoming message.

When receiving a SOAP message using an implementation of the Abstract Transmission Optimization Feature, a SOAP node binding MUST enable the Abstract Transmission Optimization Feature.

Editorial note: HR

We should decide on a SHOULD or on a MAY. In addition, the http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizationCandidates property is not very meaningful on the receiver side. We may create another property for reflecting element information items whose transmission was effectively optimized (an efficient implementation will provide this property to allow efficient retrieval of the optimized element information items).

2.4.3 Intermediaries

The usage of the Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path. Therefore, no changes or restrictions to the SOAP processing model are introduced by this feature at an intermediary. 2.4.4 Binding Optimizations at Intermediaries details the means by which certain optimizations can be performed by bindings at intermediaries. Note that dm:type is used only as a means of facilitating hop-by-hop optimization: it does not in general affect processing at a SOAP receiver, and values of dm:type are not in general preserved when relaying through an intermediary.

However a SOAP intermediary implementing the Abstract Transmission Optimization Feature MUST still follow the rules related to the usage of an implementation of the Abstract Transmission Optimization Feature when receiving the message (see 2.4.2 Receiving a message) and those related to the usage of an implementation of the Abstract Transmission Optimization Feature when sending the message (see 2.4.1 Sending a message). In addition, it MUST follow the rules for relaying SOAP messages (see [SOAP Part 1] Relaying SOAP Messages).

Editorial note: HR
This section need to be revisited.

2.4.4 Binding Optimizations at Intermediaries

As described in [SOAP Part 1] Relaying SOAP Messages, a SOAP intermediary may be called upon to to relay intact certain headers, or to reinsert headers identical to those received and removed for processing. Furthermore, many intermediaries will relay unmodified the contents of the SOAP body. In all these cases, portions of the relayed message have content identical to corresponding portions of the inbound message.

The Abstract Transmission Optimization Feature does not require any particular correspondence between the optimization of the inbound message and the outbound message, even when optimized portions of the inbound message are relayed intact, or reinserted in identical form in the envelope Infoset. Nonetheless, the implementations of the receiving binding and the binding used to transmit the relayed message MAY cooperate to provide efficient relay. For example, if the inbound and outbound binding use the same representation for optimized binary, the implementations MAY cooperate to pass the optimized form directly from the inbound to the outbound binding. The choice of whether to implement such cooperation, and if so the means used, is at the discretion of the binding specification(s) and/or the implementation of the bindings. In support of such cooperation, the inbound binding MAY make available to the outbound binding the received values of some or all dm:type accessors.

Note: a consequence of these rules is that there are no invariant rules for the degree to which optimizations are preserved as a message passes through intermediaries. Certain outbound bindings may be incapable of any optimization, and will therefore transmit unoptimized forms in all cases. Other bindings may be capable of optimization, but may or may not choose to or succeed in optimizing the same portions (if any) that were optimized in the inbound message. Other bindings, perhaps under the direction of logic provided in SOAP modules or perhaps as consequence of conventions embodied in the bindings, may optimize portions of the message that were not optimized inbound, or which were optimized using different techniques.

Editorial note: HR
This section need to be revisited.

3. Inclusion Mechanism

Editorial note: HR
This whole section is removed as it has been replaced by the MIFFY specification (ref?).

4. HTTP Transmission Optimization Feature

4.1 Introduction

The HTTP Transmission Optimization Feature is a binding-level feature implementing the Abstract Transmission Optimization Feature in an HTTP binding. This HTTP Transmission Optimization Feature uses the 3. Inclusion Mechanism as the basis of its implementation.

The HTTP Transmission Optimization Feature is a binding-level feature implementing the Abstract Transmission Optimization Feature in an HTTP binding. This HTTP Transmission Optimization Feature uses the MIFFY format (ref?) as the basis of its implementation.

This HTTP Transmission Optimization Feature builds upon the current HTTP binding (see [SOAP Part 2] SOAP HTTP Binding), enhancing it with the support of the Abstract Transmission Optimization Feature. In all aspects not described in this section, the rules of the HTTP binding are not modified.

4.2 HTTP Transmission Optimization Feature Name

This HTTP Transmission Optimization Feature is identified by the URI:

"http://www.w3.org/2003/06/soap/features/http-optimization".

4.3 Implementation

The HTTP Transmission Optimization Feature uses the 3. Inclusion Mechanism for implementing the Abstract Transmission Optimization Feature. It serializes the SOAP message using the ??? and puts the resulting MIME Multipart/Related packaging in the HTTP body.

The HTTP Transmission Optimization Feature uses the MIFFY format (ref?) for implementing the Abstract Transmission Optimization Feature. The SOAP message is encapsulated in a MIME Multipart/Related package following the rules of the MIFFY format and this MIME Multipart/Related package is put into the HTTP body.

4.3.1 Sending a SOAP message

When sending a SOAP message for which the Abstract Transmission Optimization Feature is enabled, the HTTP Transmission Optimization Feature optimizes the transmission of the message by serializing it using the ???. Unless otherwise stated, serializing a SOAP message infoset into the HTTP body MUST be semantically equivalent to performing the following steps separately, and in the order given.

When sending a SOAP message for which the Abstract Transmission Optimization Feature is enabled, the HTTP Transmission Optimization Feature optimizes the transmission of the message by serializing it using the MIFFY format (ref?). Unless otherwise stated, serializing a SOAP message infoset into the HTTP body MUST be semantically equivalent to performing the following steps separately, and in the order given.

Serialize the SOAP Message into a MIME Multipart/Related packaging as described in the MIFFY format (ref?).
Serialize the MIME Multipart/Related packaging into the HTTP body.

Editorial note: HR
Should specify what to do for the content type.

4.3.2 Receiving a SOAP message

When receiving a SOAP message using the HTTP Transmission Optimization Feature, the HTTP binding MUST, at least logically, provide access to the reconstructed SOAP message infoset.

The reconstruction of the SOAP message infoset from the data contained in the HTTP Body MUST be semantically equivalent to performing the following steps separately, and in the order given.

Extract the MIME Multipart/Related packaging from the HTTP body.
Deserialize the SOAP message from the MIME Multipart/Related packaging as described in ???.

Deserialize the SOAP message from the MIME Multipart/Related packaging according to the rules of the MIFFY format (ref?).

A. Mapping between Infosets and Data Models

Editorial note: HR
This section should be revisited as XQDM appears only in the MIFFY format.

The SOAP Recommendation models message envelopes as XML Infosets; this feature uses the XQuery 1.0 and XPath 2.0 Data Model to augment the information available in such Infosets with typing information, which is used as the basis for optimization. This Appendix sets out in detail the correspondence between SOAP Infosets and SOAP data models, for purposes of implementation of this feature.

A.1 Infoset Mapping at Sending Nodes

The [XML Query Data Model] provides a normative mapping from the Post Schema Validation Infoset to a data model. Except as specified here, that mapping is used to construct data models from SOAP envelope infosets at a sending node. The differences are as follows:

Neither SOAP nor this feature requires schema validation of messages by sender or receiver. The means by which dm:type and dm:typed-value are determined are at the discretion of the sending SOAP node, except that the dm:typed-value must be consistent with the dm:string-value for the assigned dm:type.
In the case where no type information is available, perhaps because no schema validation was performed or because no type was assigned by such validation, the conventions described at dm:type. MUST be used to indicate that the type is indeterminate.

Editorial note: NRM
Should xdt:untypedAtomic be used for leaf nodes with only text content? Seems preferable to me, but for some reason the dm is looser.

A.2 Infoset Mapping at Receiving Nodes

The [XML Query Data Model] provides a normative mapping from a Data Model to an Infoset. That mapping is used to construct the SOAP envelope Infoset at the receiver. Note that this mapping makes use only of dm:string and text node dm:children: in no case is the dm:type or dm:typed-value used to construct the Infoset. Thus, this mapping enforces the goal of this feature, which is to use type information as a means of optimization, but not to affect the semantics of SOAP processing.

B. References

[SOAP Part 1]: W3C Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See http://www.w3.org/TR/soap12-part1/.)
[SOAP Part 2]: W3C Recommendation "SOAP Version 1.2 Part 2: Adjuncts", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, May 2003. (See http://www.w3.org/TR/soap12-part2/.)
[SOAP 1.2 Attachment Feature]: W3C Working Draft "SOAP 1.2 Attachment Feature", H. F. Nielsen, H. Ruellan, September 2002. (See http://www.w3.org/TR/soap12-af/.)
[SOAP Attachment Requirements]: W3C Editors' copy "SOAP Attachment Feature Requirements", M. A. Jones, May 2003. (See http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html.)
[XML 1.0]: W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.)
[Namespaces in XML]: W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)
[XML InfoSet]: W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)
[XML Schema Part 1]: W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)
[XML Schema Part 2]: W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)
[XML Schema Part 2 Errata]: W3C Internal Working Draft 7 March 2003 Id: datatypes-with-errata.xml,v 1.5 2003/03/07 19:54:00 (See http://www.w3.org/XML/Group/2002/09/xmlschema-2/datatypes-with-errata.html.)
[RFC 2119]: IETF "RFC 2119: Keywords for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
[RFC 2387]: IETF "The MIME Multipart/Related Content-type", E. Levinson, August 1998. (See http://www.ietf.org/rfc/rfc2387.txt.)
[PASWA]: "Proposed Infoset Addendum to SOAP Messages with Attachments", April 2003. (See http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.)
[XML Query Data Model]: "XQuery 1.0 and XPath 2.0 Data Model", April 2003. (See http://www.w3.org/TR/xpath-datamodel/.)

C. Change Log (Non-Normative)

Table 2: Changes since first draft.
Who	When	What
HR	20031124	Modify the specification to refer to the MIFFY format.
NRM	20031008	Major change to convert to XQuery data model formulation. Re-integrated text on optimization through intermediaries, adding a few DM-related sentences to the sections on intermediaries and binding optimizations through intermediaries.
NRM	20030917	Integrated new text on optimization through intermediaries, which should close issue 431.
HR	20030703	Changed 1. Introduction paragraph 2 to include Noah's text on hop-by-hop contract.
HR	20030703	Changed ??? bullet 4 as per Gudge suggestion (ie "the content" of each eii). Changed bullet 3 in the same way.
HR	20030703	Added Introductory text from Jacek relating document to PASWA and telling about future inclusion of PASWA related stuff.
HR	20030701	Added relation with requirements document.
HR	20030630	Added an URI table as in other specs, and a Notational Convention section.
HR	20030630	Named properties with URIs.
HR	20030630	Put all eii and aii names in monospace.
HR	20030630	Corrected specific typos found by Tony Graham.
HR	20030620	Split up HTTP implementation into an 3. Inclusion Mechanism and an 4. HTTP Transmission Optimization Feature using this 3. Inclusion Mechanism
HR	20030620	Added a link to other specification section (1.2 Relation to other specifications).
HR	20030620	Added a references section (B. References).
HR	20030620	Changed main title from "Optimization Mechanism" to "SOAP Message Transmission Optimization Mechanism".
HR	20030620	Changed abstract feature name from "Abstract Optimization Feature" to "Abstract Transmission Optimization Feature".
HR	20030620	Changed/removed all occurences of "Working Draft".
HR	20030620	Removed all colored-diff marks.
HR	20030618	Changed document's name from "Inclusion Mechanism" to "Optimization Mechanism", and changed abstract feature name and HTTP feature name.
HR	20030618	Corrected typos and other editorial errors.
HR	20030618	Added a publication date.
HR	20030618	Added an abstract.
HR	20030618	Improved general introduction (1. Introduction).
HR	20030618	Changed the presentation of the processing rules in 2.4.1 Sending a message, 2.4.2 Receiving a message.
HR	20030618	Shortened aof-transmitting.
HR	20030618	Improved HTTP implementation introduction (4.1 Introduction).
HR	20030618	Added a description of the `Include` element information item and of the `href` attribute information item.
HR	20030618	Changed the presentation for sending a SOAP message through the HTTP binding.
HR	20030618	Improved the presentation for receiving a SOAP message through the HTTP binding.