INTERNET-DRAFT Henrik Frystyk Nielsen, draft-nielsen-dime-soap-01 Erik Christensen Microsoft, Joel Farrell IBM Expires December 2002 June 17, 2002 WS-Attachments Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at "http://www.ietf.org/ietf/1id-abstracts.txt" The list of Internet-Draft Shadow Directories can be accessed at "http://www.ietf.org/shadow.html". Please send comments to the "dime@discuss.develop.com" mailing list, which is archived at "http://discuss.develop.com/dime.html". Abstract This document defines an abstract model for SOAP attachments and based on this model defines a mechanism for encapsulating a SOAP message and zero or more attachments in a DIME message. SOAP attachments are described using the notion of a compound document structure consisting of a primary SOAP message and zero or more related documents known as attachments. Nielsen, et al. [Page 1] INTERNET-DRAFT WS-Attachments June, 2002 Table of Contents 1 Introduction................................................2 1.1 Notational Conventions...................................3 2 Compound SOAP Structures....................................3 2.1 Terminology..............................................3 2.2 Compound SOAP Structure Model............................4 2.3 Representing Compound SOAP Structures....................5 3 Representing a Compound SOAP Structure in DIME..............7 3.1 Encapsulating a Compound SOAP Structure..................7 3.2 Usage of URI References..................................9 3.2.1 Determining a Base URI................................10 3.2.2 Matching URI References...............................11 4 DIME and SOAP Underlying Protocol Bindings.................12 4.1 SOAP 1.2 HTTP Binding Interactions......................12 4.2 SOAP 1.1 HTTP Binding Interactions......................13 5 Internationalization Considerations........................13 6 Security Considerations....................................13 7 IANA Considerations........................................14 8 Intellectual Property......................................14 9 Acknowledgements...........................................14 10 References.................................................15 11 Authors' Addresses.........................................16 1 Introduction SOAP provides a flexible and extensible envelope for describing structured information intended for exchange between SOAP nodes. While SOAP 1.1 is described in terms of XML [12], SOAP 1.2 [17] [18] is described in terms of XML Infoset [14]. In both cases, however, XML is expected to be a widely used representation. Assuming an XML-based representation, there are certain inherent limitations in dealing with three particular issues: 1. Encapsulation of binary data in the form of image files etc. cannot be done without additional encoding/decoding of the data. The overhead of encoding binary data in a form acceptable to XML (for example using base64 [2]) is often significant both in terms of bytes added because of the encoding as well as processor overhead performing the encoding/decoding. 2. Encapsulation of other XML documents as well as XML fragments is cumbersome within a SOAP message--especially if the XML parts do not use the same character encoding. Nielsen, et al. [Page 2] INTERNET-DRAFT WS-Attachments June, 2002 3. Although SOAP messages inherently are self-delimiting, the message delimiter can only be detected by parsing the complete message. This can imply a significant overhead in generic message processing as well as parsing and memory allocation. The W3C Note "SOAP with Attachments" [16] addresses point 1 and 2 above. However, MIME multipart itself adds extra parsing overhead in order to determine the various parts of the MIME message. In addition, while MIME is a successful general message description format, the problem of encapsulating and delimiting messages is a much more focused problem that does not require the full expressiveness of MIME. DIME [10] is a simple, lightweight message format that has been explicitly limited to provide a few core services needed for encapsulating messages. The purpose of this document is to describe how to use existing facilities provided by SOAP, DIME, and URIs to encapsulate SOAP messages and related documents (often known as attachments). 1.1 Notational Conventions The key words "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 [5]. 2 Compound SOAP Structures The encapsulation of SOAP messages in DIME is based on an abstract concept of a multi-component entity called a "compound SOAP structure". This section defines the properties of a compound SOAP structure and the requirements to a concrete representation of such a structure. Section 3 defines a concrete representation based on DIME, and section 4 defines the interactions between the DIME representation and underlying protocols. 2.1 Terminology Compound SOAP structure A compound SOAP structure consists of a primary SOAP message part and zero or more related secondary parts. Nielsen, et al. [Page 3] INTERNET-DRAFT WS-Attachments June, 2002 Primary SOAP message part A SOAP message that provides the processing context for the compound SOAP structure as a whole including the secondary parts. Secondary Part A document or entity related to the primary SOAP message part in some manner. A secondary part is a resource in the sense that it has identity and is identified by a URI. The representation of the resource can be of any type and size. 2.2 Compound SOAP Structure Model A compound SOAP structure consists of a primary SOAP message part and zero or more related secondary parts that are distinct from the primary SOAP message but related to it in some manner. Secondary parts can be used to contain data that naturally represents a resource in its own right or which is cumbersome to represent within the primary SOAP message part. The latter can be due to the size, type, or format of the data--a secondary part may be an audio clip, an image, or a very large view of a database, for example. Secondary parts are often informally referred to as "attachments". While the attachment relationship is expected to be commonly used, the model makes no assumption about the nature of the relationship between the primary SOAP message part and secondary parts, or between secondary parts. It is important to note that the compound SOAP structure model does not modify or supersede the message concept defined by SOAP. Nor does it define a processing model for any of the parts of a compound SOAP structure including the primary SOAP message part. The processing model for the primary SOAP message part is defined by SOAP. The application-defined semantics of the SOAP message provides the processing context for the secondary part(s). Each part is identified by a URI that can be used to reference it from other parts. The URI identifying a part can be of any URI scheme. It is RECOMMENDED that only IANA registered URI schemes [9] be used. Nielsen, et al. [Page 4] INTERNET-DRAFT WS-Attachments June, 2002 The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise verify any secondary parts of a compound SOAP structure. It is up to the SOAP receiver to determine, based on the processing context provided by the primary SOAP message part, which operations must be performed (if any) on the secondary part(s). 2.3 Representing Compound SOAP Structures The compound SOAP structure model is abstract in the sense that it does not define an actual representation of a compound SOAP structure. This section describes the requirements to a specification defining a representation of a compound SOAP structure. Section 3 and 4 define a representation of a compound SOAP structure using DIME as the encapsulation mechanism. This does not preclude the definition of other representations; the definition of such additional representations is outside the scope of this specification. A representation of a compound SOAP structure MUST describe the following three parts: o An encapsulation mechanism for the primary SOAP message part and for each secondary part. The encapsulation mechanism MAY but NEED NOT be the same for all parts. o A mechanism by which all parts can be identified using a URI reference. While the reference MUST be in the form of a URI, the mechanism by which the URI is represented MAY but NEED NOT be the same for all parts. o The interactions between the unit of encapsulation and the underlying protocols supporting that unit of encapsulation. The compound SOAP structure model is independent of the underlying protocol used for exchanging the primary SOAP message part and any of the secondary parts. That is, there is no requirement that all parts of a compound SOAP structure representation be exchanged within the same unit of the underlying protocol. Note that in some cases, the encapsulation mechanism may also provide the functionality of the underlying protocol but this is not a requirement. A representation of a compound SOAP structure SHOULD NOT presume any particular message exchange pattern, message correlation or any Nielsen, et al. [Page 5] INTERNET-DRAFT WS-Attachments June, 2002 other feature that may be required in order to exchange SOAP messages. As examples of possible representations, a compound SOAP structure consisting of a primary SOAP message part containing an insurance claim for a damaged car and a secondary part containing a JPEG image of the car, can be represented in several ways including but not limited to the following: 1. The primary SOAP message part and the JPEG image may be encapsulated in a single DIME message and exchanged using an underlying protocol like TCP or HTTP [8] (see section 3 and 4). 2. The primary SOAP message part may be exchanged using the HTTP protocol binding without any further encapsulation and the JPEG image exchanged using a separate HTTP GET request. This representation is not formally defined by this specification but only provided as an example. A representation MUST unambiguously indicate either explicitly or implicitly which part is the primary SOAP message part. A SOAP receiver implementing a particular representation of a compound SOAP structure MUST process the primary SOAP message part according to the rules for processing SOAP messages [15] [17]. Representations of compound SOAP structures MAY be nested by having a secondary part of one representation contain a representation of another compound SOAP structure. In this case, the primary SOAP message part is the primary SOAP message part of the outermost representation and as for any other secondary part, the semantics of the primary SOAP message part provides the processing context for the nested representation(s). While representations MAY provide mechanisms for verifying the integrity and enumerating the parts of a compound SOAP structure, this is not a requirement of the compound SOAP structure model. In the remaining part of this specification, we define a representation of a compound SOAP structure using DIME as the encapsulation mechanism. Nielsen, et al. [Page 6] INTERNET-DRAFT WS-Attachments June, 2002 3 Representing a Compound SOAP Structure in DIME This specification defines the mechanisms needed in order to represent a compound SOAP structure using DIME. The representation contains three parts: 1. The encapsulation of the primary SOAP message part and of secondary parts associated with that primary SOAP part as individual payloads in a DIME message (see section 3.1). 2. Rules for handling URI references between the primary SOAP message part and its secondary parts (see section 3.2). 3. A description of how the DIME encapsulation affects existing SOAP underlying protocol bindings (see section 4). While a DIME message provides an encapsulation mechanism for a SOAP message, it does not provide protocol support for exchanging SOAP messages between SOAP nodes. As such, the mechanisms defined for encapsulating SOAP in DIME constitutes a "binding property" and not a SOAP protocol binding according to the SOAP 1.2 Protocol Binding Framework (see [18]). The name by which one can refer to the binding property defined by this specification is the following URI: http://schemas.xmlsoap.org/ws/2002/06/dime/soap DIME MAY be used in, but does not require, a MIME or MIME-like environment. The DIME representation defined in this section can be used in combination with underlying protocols regardless of whether they provide a MIME environment or not. The DIME representation of a compound SOAP structure does not presume a particular message exchange pattern, or the presence of other features that may be required in order to exchange SOAP messages. 3.1 Encapsulating a Compound SOAP Structure The primary SOAP message part MUST be the first payload of the DIME message. The format of the payload MUST be an XML serialization of the primary SOAP message part. By convention, the first payload in a DIME message provides the processing context for the whole DIME message (see [10]). Nielsen, et al. [Page 7] INTERNET-DRAFT WS-Attachments June, 2002 The properties of the first DIME record are as follows: o The DIME payload type indicates that this is a SOAP envelope. Depending on the SOAP version, this is done in one of two ways: for SOAP 1.2, the value of the DIME TYPE field MUST be the MIME media type "application/soap+xml" [11]; for SOAP 1.1, as no dedicated media type is defined, the value MUST be the absolute URI "http://schemas.xmlsoap.org/soap/envelope/". o The DIME payload identifier MAY be used to identify the primary SOAP message so that it is possible to refer to it from secondary parts. The identifier is a URI as described in section 3.2. While this representation identifies the primary SOAP message part by requiring it to be the first payload in a DIME message, it does not provide a means for identifying a primary SOAP message part within the SOAP message itself, for example as part of a manifest carried within the SOAP envelope. A separate specification might describe such a mechanism. Any subsequent payloads in a DIME message MUST be secondary parts related to the primary SOAP message part. Each secondary part is encapsulated as a separate payload carried in DIME records with the following properties: o The DIME payload type is the type of the secondary part. For example, if the secondary part is a JPEG image, the DIME payload type is "image/jpeg". o The DIME payload identifier SHOULD be used to identify the secondary part so that it is possible to refer to it from the primary SOAP message part and other secondary parts. The identifier is a URI as described in section 3.2. In all cases, the DIME record length is, as defined by DIME, the length of the data carried in the DIME record. Note that a part MAY be chunked. Example 1 illustrates the sample compound SOAP message structure described in section 2.3 represented using DIME. The first payload is the primary SOAP 1.2 message part, and the remaining payloads are accompanying attachments. In this example, there is one attachment. If there are no attachments then the SOAP message is the only payload in the DIME message. Nielsen, et al. [Page 8] INTERNET-DRAFT WS-Attachments June, 2002 DIME Record 1: Primary SOAP message part TNF: 1 Type: application/soap+xml Id: DIME Record 2: Secondary part TNF: 1 Type: image/jpeg Id: uuid:09233523-345b-4351-b623-5dsf35sgs5d6 Example 1: DIME representation of sample compound SOAP structure containing a primary SOAP message part and an image as a secondary part. There is no requirement that all secondary parts of a compound SOAP structure be encoded within the same DIME message. Depending on the semantics of the primary SOAP message part, it may be appropriate to include only a subset of the secondary parts in the same DIME message as the primary SOAP message part. The DIME representation does not provide any mechanism for verifying the integrity or enumerating the parts of a compound SOAP structure. While many applications may require such mechanisms, it is an explicitly choice not to include them in this specification. 3.2 Usage of URI References The primary SOAP message part may need to refer to any secondary part and secondary parts themselves may need to refer to each other. This section defines the rules for using URI references in order to reference other parts in a DIME encoded compound SOAP construct. While the DIME representation defines a mechanism for indicating the URI of a secondary part, it does not in general prescribe a mechanism for indicating a URI reference to a secondary part or to the primary SOAP message part. However, if a reference to a part is provided within the context of the SOAP 1.1 data encoding [16], the URI reference MUST be indicated using the "href" attribute as defined by the SOAP 1.1 data encoding. The mechanism defined in this section is independent of any particular mechanism used for indicating URI references. The usage of URI references involves the following two steps: Nielsen, et al. [Page 9] INTERNET-DRAFT WS-Attachments June, 2002 1. Convert all relative URI references to absolute URI references (see section 3.2.1). 2. Match the absolute URI references used in compound SOAP structure parts with the DIME record identifier of each part in order to detect cross-references (see section 3.2.2). While the steps above apply to all URI references regardless of URI scheme, it is RECOMMENDED that when possible, globally unique identifiers such as "uuid:" URIs be used to identify compound SOAP structure parts encoded in a DIME message. DIME imposes certain length limitations on URIs used as DIME record identifiers. Please refer to the DIME specification for details on these limitations. 3.2.1 Determining a Base URI For each relative URI reference encoded in a DIME record or used as a DIME record payload identifier, a base URI can be determined using the framework provided by RFC 2396 [6]. Given a base URI, a relative URI reference can be made absolute following the rules defined by RFC 2396, section 5.2. Note, that these rules only apply to base URIs that are hierarchical in nature and hence enable relative URIs in the first place. The mechanism for determining a base URI for relative URI references used in compound SOAP structure parts is identical regardless of whether the reference is found in the primary SOAP message part or in a secondary part. The mechanism also applies to relative URI references used as DIME record identifiers. The mechanism, which consists of four rules applied in order of precedence, is as follows: 1. Base URI embedded in the parts' content: For example, the base URI for a relative URI reference may be defined using XML Base [13]. 2. Base URI of the encapsulating entity: If there is a DIME record identifier with an absolute URI as value then that URI is the base URI of the part. In the case of nested DIME messages, this step may be repeated in the order from innermost to outermost in order to determine the most specific base URI. Nielsen, et al. [Page 10] INTERNET-DRAFT WS-Attachments June, 2002 3. The URI used to retrieve the entity: If the underlying protocol provides a URI used for retrieving the entity then that URI is the base URI. 4. Default Base URI: If the URI reference is not a same-document reference as defined by RFC 2396, section 4.2, the default base URI is "thismessage:/" as defined by RFC 2557 [7]. The use of this special URI scheme enables relative URI references used in different parts encoded within the same DIME message to share a common (fictitious) base URI. Note that while these rules are applicable to same-document URI references such as an empty URI reference or a URI reference containing only a fragment identifier, such references may not need to be made absolute in order to be dereferenced (see RFC 2396, section 4.2 and XInclude [19]). 3.2.2 Matching URI References Once absolute URI references are determined as described in section 3.2.1, it is possible to match the URI references found in the compound SOAP structure parts encoded in a DIME message with the URI references used to identify the parts. As mentioned in section 2.3 it is not a requirement that URI references be dereferenced or otherwise verified by the SOAP receiver. Such operations are determined by the processing semantics of the context in which the reference is found. Example 2 provides a sample primary SOAP message part illustrating a reference to a secondary part using a "uuid:" URI. Nielsen, et al. [Page 11] INTERNET-DRAFT WS-Attachments June, 2002 ... ... Example 2: Given the DIME encoded compound SOAP structure illustrated in Example 1, the primary SOAP message part can refer to the secondary part using the URI "uuid:09233523-345b-4351-b623-5dsf35sgs5d6". This specification does not provide any equivalence rules for URIs as these are defined by the individual URI schemes and by RFC 2396 [6]. Because of inconsistencies with respect to some URI equivalence rules in many current URI parsers, it is STRONGLY RECOMMENDED that URI matching only rely on the most rudimentary equivalence rules defined by RFC 2396. 4 DIME and SOAP Underlying Protocol Bindings Depending on the underlying protocol binding, using DIME for encoding compound SOAP structures may affect the parameters of the underlying protocol binding. This specification describes the interactions between the DIME representation and the HTTP binding for SOAP 1.2 and SOAP 1.1 respectively. The DIME representation MAY be used in combination with other protocol bindings. In this case, the specification for such bindings SHOULD describe any interactions with the DIME representation. 4.1 SOAP 1.2 HTTP Binding Interactions A DIME encoded compound SOAP structure is in all regards identical to the SOAP 1.2 HTTP protocol binding but for the following two exceptions: 1. The HTTP Content-Type header field MUST have a value of "application/dime" rather than "application/soap+xml" as defined by SOAP 1.2 [11]. Nielsen, et al. [Page 12] INTERNET-DRAFT WS-Attachments June, 2002 2. The DIME message constitutes the HTTP entity body and must appear as described in section 3.1. 4.2 SOAP 1.1 HTTP Binding Interactions The rules for forming an HTTP message containing a DIME encoded compound SOAP structure follows the SOAP 1.1 HTTP protocol binding in all regards but for the following two exceptions: 1. The HTTP Content-Type header field MUST have a value of "application/dime" rather than "text/xml" as defined by SOAP 1.1. 2. The DIME message constitutes the HTTP entity body and must appear as described in section 3.1. The SOAPAction HTTP header field is unaffected by the DIME encapsulation. 5 Internationalization Considerations This specification does not introduce internationalization considerations beyond what is introduced by SOAP, DIME, and URIs. This specification refers to the considerations described by those specifications. 6 Security Considerations Implementers should pay special attention to the security implications of any payload types that can cause the remote execution of any actions in the recipient's environment. Before accepting payloads of any type, an application should be aware of the particular security implications associated with that type. This applies not only to compound SOAP structure parts encapsulated in DIME but to any part regardless of the encapsulation. Security considerations for media types in general are discussed in RFC 2048 [4] and in the context of the "application/postscript" and the "message/external-body" media type in RFC 2046 [3]. To address concerns about integrity and confidentiality, attachments can be digitally signed and encrypted. A compound SOAP structure that includes signed or encrypted attachments would Nielsen, et al. [Page 13] INTERNET-DRAFT WS-Attachments June, 2002 include security information about the attachments in the security header of the primary SOAP message part. The WS-Security specification [20] provides a means to protect a message by encrypting and/or digitally signing a body, a header, an attachment, or any combination of them (or parts of them). Note: This specification does not presently define any mechanisms for binding a SOAP payload to a DIME header to prevent certain classes of security attacks. Future versions of this specification will address this open issue. 7 IANA Considerations This specification does not describe any components that require registration by IANA. 8 Intellectual Property The following notice is copied from RFC 2026 [1], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the procedures of the IETF with respect to rights in standards- track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9 Acknowledgements @@@TBD@@@ Nielsen, et al. [Page 14] INTERNET-DRAFT WS-Attachments June, 2002 10 References [1] S. Bradner, "The Internet Standards Process û Revision 3", RFC 2026, Harvard University, October 1996 [2] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996 [3] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft First Virtual, November 1996 [4] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Innosoft, MCI, ISI, November 1996 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [6] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998. [7] J. Palme, A. Hopmann, N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm University/KTH, Microsoft Corporation, Lotus Development Corporation, March 1999 [8] R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T. Berners-Lee, "Hypertext Transfer Protocol û HTTP/1.1", RFC 2616, U.C. Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997 [9] List of Uniform Resource Identifier (URI) schemes registered by IANA is available at "http://www.iana.org/assignments/uri-schemes" [10] H. Nielsen, H. Sanders, E. Christensen, "Direct Internet Message Encapsulation (DIME)", INTERNET DRAFT "http://www.ietf.org/internet-drafts/draft-nielsen-dime- 02.txt", Microsoft, May 2001. This is work in progress. [11] M. Baker, M. Nottingham, "The "application/soap+xml" media type", INTERNET DRAFT "http://www.ietf.org/internet- drafts/draft-baker-soap-media-reg-00.txt", Planetfred, Inc., January 14, 2002. This is work in progress. [12] W3C Recommendation, "Extensible Markup Language (XML) 1.0 (Second Edition)", "http://www.w3.org/TR/2000/REC-xml- 20001006", 6 October 2000 [13] W3C Recommendation, "XML Base", "http://www.w3.org/TR/2001/REC-xmlbase-20010627/", 27 June 2001 [14] W3C Recommendation, "XML Information Set", "http://www.w3.org/TR/2001/REC-xml-infoset-20011024", 24 October 2001 [15] W3C Note, "Simple Object Access Protocol (SOAP) 1.1", "http://www.w3.org/TR/2000/NOTE-SOAP-20000508/", 8 May 2000 [16] W3C Note, "SOAP Messages with Attachments", "http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211", 11 December 2000 Nielsen, et al. [Page 15] INTERNET-DRAFT WS-Attachments June, 2002 [17] W3C Working Draft, "SOAP Version 1.2 Part 1: Messaging Framework", "http://www.w3.org/TR/2001/WD-soap12-part1-20011217/". This is work in progress. [18] W3C Working Draft, "SOAP Version 1.2 Part 2: Adjuncts", "http://www.w3.org/TR/2001/WD-soap12-part2-20011217/". This is work in progress. [19] W3C Candidate Recommendation, "XML Inclusions (Xinclude) Version 1.0", "http://www.w3.org/TR/2002/CR-xinclude- 20020221". [20] B. Atkinson, et al, "Web Services Security (WS-Security)", Draft, "http://www- 106.ibm.com/developerworks/webservices/library/ws-secure/" or "http://msdn.microsoft.com/ws/2002/04/Security/" 11 Authors' Addresses Henrik Frystyk Nielsen Microsoft One Microsoft Way, Redmond, WA 90852 Email: henrikn@microsoft.com Erik Christensen Microsoft One Microsoft Way, Redmond, WA 90852 Email: erikc@microsoft.com Joel Farrell IBM One Rogers St. Cambridge, MA 02142 Email: joelf@us.ibm.com Nielsen, et al. [Page 16]