index.html 29 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head><title>SOAP Optimized Serialization Use Cases and Requirements</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>
<h1><a id="title" name="title" />SOAP Optimized Serialization Use Cases and Requirements</h1>
<h2><a id="w3c-doctype" name="w3c-doctype" />W3C Working Draft 8 June 2004</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/">http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/soap12-os-ucr/">http://www.w3.org/TR/soap12-os-ucr/</a></dd><dt>Previous version:</dt><dd>
      <a href="http://www.w3.org/TR/2003/WD-soap12-os-ucr-20031112/">
	http://www.w3.org/TR/2003/WD-soap12-os-ucr-20031112/</a>
    </dd><dt>Editors:</dt><dd>Tony Graham, Sun Microsystems</dd><dd>Anish Karmarkar, Oracle Corp.</dd><dd>Mark Jones, AT&amp;T</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr /><div>
<h2><a id="abstract" name="abstract" />Abstract</h2><p>This document records the use cases and specifies the
requirements for optimizing the processing and serialization of SOAP
messages.</p></div><div>
<h2><a id="status" name="status" />Status of this Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p><p>
The use cases and requirements described in this document serve to
motivate and constrain the scope of the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a>'s (WG)
work on a <a href="http://www.w3.org/TR/soap12-mtom/">SOAP Message Transmission Optimization Mechanism</a>. This
publication is the result of the work started in February 2003 by the WG.
The WG does not expect there will be any changes to the use cases and
requirements in the future, although the WG may consider comments on
them. Send comments on this document to <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a> mailing list
<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">(public
	  archive)</a>. The <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a> is part of the <a href="http://www.w3.org/2002/ws/Activity"> Web Services
	  Activity</a>.
</p><p>Discussion of this document takes place on the public <a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a> mailing
list (Archives <a href="#xml-dist-app">[XMLP Archive]</a>) per the <a href="http://www.w3.org/2004/02/XML-Protocol-Charter#email">email
communication rules</a> in the XML Protocol Working Group Charter
<a href="#xmlp-charter">[XMLP Charter]</a>.</p><p>This document has been produced under the
<a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended
by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>.
An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s)
 with respect to this specification should disclose the information in accordance with section 6 of the
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">W3C Patent Policy</a>.
	Patent disclosures relevant to this specification may be found on the
	Working Group's <a href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent
	  disclosure page</a>.
      </p><p>Publication as a Working Draft does not imply endorsement
by the W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than work in
progress.</p></div><div class="toc">
<h2><a id="contents" name="contents" />Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
2 <a href="#terminology">Terminology</a><br />
3 <a href="#use-cases">Use Cases</a><br />
    3.1 <a href="#out-of-scope-use-cases">Out of Scope Use Cases</a><br />
4 <a href="#requirements">Requirements</a><br />
    4.1 <a href="#considerations">Considerations</a><br />
    4.2 <a href="#processing">Processing Environment Requirements</a><br />
    4.3 <a href="#wire">Infoset Serialization Requirements</a><br />
    4.4 <a href="#binding">Binding Requirements</a><br />
5 <a href="#refs">References</a><br />
</p>
<h3><a id="appendices" name="appendices" />Appendices</h3><p class="toc">A <a href="#acknowledgments">Acknowledgments</a> (Non-Normative)<br />
B <a href="#changelog">Change Log</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a id="introduction" name="introduction" />1 Introduction</h2><p>SOAP Version 1.2 <a href="#SOAP12-1">[SOAP Part 1]</a><a href="#SOAP12-2">[SOAP Part 2]</a> is a lightweight protocol intended for exchanging
structured information in a decentralized, distributed environment.
This document records the use cases and specifies the requirements for
optimizing the processing and serialization of SOAP messages.</p><p>The use cases illustrate the reasons for optimizing the
serialization of SOAP messages.</p><p>The requirements distill both the constraints embodied in the
use cases and the features necessary for interoperability with
existing protocols, bindings, and serialization formats such as SOAP
1.2, WSDL, MIME, etc.  Two influential developments shaped these
requirements:</p><ul><li><p>The "SOAP Messages with Attachments" <a href="#swa">[SwA]</a> W3C Note
provided a MIME multipart/related packaging scheme that related
accompanying "entities" (including binary data) to a SOAP 1.1 message
via referencing rules.  The SwA approach did not, however, naturally
integrate attachments into the SOAP processing model and the XML
Infoset representation of a SOAP message.</p></li><li><p>The PASWA document <a href="#paswa">[PASWA]</a>, a "Proposed Infoset Addendum to SOAP Messages with
Attachments", offered a more unified approach by suggesting that the
accompanying entities be logically considered a part of the SOAP
message XML Infoset, while retaining the flexibility for
implementations to optimize their behavior.</p></li></ul></div><div class="div1">
<h2><a id="terminology" name="terminology" />2 Terminology</h2><p>The terminology and processing reflected in these
requirements supercede and are not necessarily consistent with the
SOAP 1.2 Abstract Feature specification <a href="#xmlp-abstract-attachment-feature">[Attachment Feature]</a>.  For example, the term
<em>part</em> does not necessarily indicate attachment data that
is logically outside the SOAP envelope infoset.  It may also cover
data in alternative serializations that is logically contained in the
SOAP envelope infoset.</p></div><div class="div1">
<h2><a id="use-cases" name="use-cases" />3 Use Cases</h2><div class="note"><p class="prefix"><b>Note:</b></p><p>More use cases were submitted to the XMLP WG than were
accepted for inclusion in this list.  The use cases up to UC11
preserve their numbering from the discussion <a href="#uc-summary">[UC Summary]</a> prior to their inclusion in this document.
Omitting rejected use cases has left gaps in the numbering.</p></div><dl><dt class="label"><a id="uc2" name="uc2" />UC2: Resource “Bundled” with Message</dt><dd><p>An application wishes to send a URI in a message, and
the receiver will dereference the URI. The sender chooses to “bundle”
a representation of the resource in the message as well, so that the
receiver may choose this representation when it dereferences the
URI. This is useful in cases when the resource identified by the URI
is inaccessible to the receiver, or the receiver wants to avoid the
overhead of dereferencing the resource over the network, etc.</p></dd><dt class="label"><a id="uc6" name="uc6" />UC6: Message Containing “Redundant” Pieces of Binary Data</dt><dd><p>An application wishes to send a SOAP message that contains redundant pieces of binary data. Each such piece of binary data is actually contained in several locations of the SOAP message (for example, the SOAP message could contain an XML document which includes in several locations the PNG logo of the company which authored the document). For design reasons, this data cannot be referenced externally, but must be transported with the message. Doing so by copying each piece of binary data as many times as it is contained in the SOAP message involves an unacceptable message size, due to bandwidth, latency and/or storage requirements.</p></dd><dt class="label"><a id="uc9" name="uc9" />UC9: Undesirable Message Bloat</dt><dd><p>An application wishes to send a SOAP message that
contains one or more large binary pieces of data; e.g., a JPG image, binary
executable or other sizeable, non-textual data. For design reasons,
this data cannot be referenced externally, but must be transported
with the message. Doing so using base64Binary or similar encoding
involves an unacceptable message size, due to bandwidth, latency
and/or storage requirements.</p></dd><dt class="label"><a id="uc10" name="uc10" />UC10: Undesirable Processing Overhead</dt><dd><p>An application wishes to send a SOAP message that
contains one or more large binary pieces of data; e.g., a JPG image, binary
executable or other sizeable, non-textual data. For design reasons,
this data cannot be referenced externally, but must be transported
with the message. Doing so using base64Binary or similar encoding
involves unacceptable message generation and/or parsing overhead, due
to throughput requirements, device limitations and/or other
considerations.</p></dd><dt class="label"><a id="uc11" name="uc11" />UC11: Focused Intermediaries</dt><dd><p>An intermediary wishes to process a large message, but
only needs to access a small section of the message. For efficient
operation, it needs to be able to construct the relevant parts of the
message infoset without actually reading and parsing the rest of the
message, whilst still being able to successfully forward the entire
message.</p></dd></dl><div class="div2">
<h3><a id="out-of-scope-use-cases" name="out-of-scope-use-cases" />3.1 Out of Scope Use Cases</h3><p>The Working Group recognizes that optimizing the serialization
of SOAP messages is applicable to the following use cases but decided that
it would not develop requirements to satisfy these.</p><dl><dt class="label"><a id="uc12" name="uc12" />UC12: Interleaving</dt><dd><p>An application may want to interleave the optimized serializations of multiple portions of a message, so that it can be produced and/or consumed incrementally and simultaneously. This could be useful, for example, to applications that produce/consume audio and video streams simultaneously.</p></dd></dl></div></div><div class="div1">
<h2><a id="requirements" name="requirements" />4 Requirements</h2><p>The requirements below are coarsely categorized as applying
to the SOAP/WSDL processing environment (general issues, abstract
features and properties, WSDL compatibility, etc.), as arising
primarily at the concrete wire format level (serialization,
representation, metadata, etc.), or as constraining the binding.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The requirements are numbered in the order in which they
were considered by the XMLP WG. Omitting rejected requirements has
left gaps in the numbering.</p><p>The grouping and ordering of the requirements in the following
sections is for ease of reading and does not indicate any relative
priority of any of the requirements.</p></div><div class="div2">
<h3><a id="considerations" name="considerations" />4.1 Considerations</h3><p>There are general, high-level considerations in choosing a
design for a SOAP Attachment Feature which should be taken as input in
addition to the specific requirements listed in the following
sections.</p><ul><li><p>If existing packaging schemes (e.g., Multipart-MIME,
DIME, ZIP, tar, jar, etc.) meet the requirements, or represent
sensible tradeoffs, then the specification should use such existing
schemes.</p></li><li><p>The specification should, where reasonably practical, be
designed to facilitate message construction, parsing, debugging,
tracing, implementation optimizations and other diagnostic
activities.</p></li></ul></div><div class="div2">
<h3><a id="processing" name="processing" />4.2 Processing Environment Requirements</h3><dl><dt class="label"><a id="r9" name="r9" />R9</dt><dd><p>The specification must describe its points of
extensibility.</p></dd><dt class="label"><a id="r15" name="r15" />R15</dt><dd><p>The interface created by the specification should be conveniently
describable by languages such as WSDL.</p></dd><dt class="label"><a id="r32" name="r32" />R32</dt><dd><p>The specification must be specified using the mechanisms of SOAP
1.2. These may include features, binding specifications, headers,
relaying of information through intermediaries, etc.  All processing
must be specified in terms of the SOAP processing model, as augmented
by any new features introduced.  Where practical, the optional
mechanisms of SOAP 1.2 (such as A Convention for Describing Features
and Bindings) should be used in the description of the
optimized serialization.</p></dd><dt class="label"><a id="r18" name="r18" />R18</dt><dd><p>The specification must support transmission of messages to down-level
receivers that do not understand the specification.</p></dd><dt class="label"><a id="r27" name="r27" />R27</dt><dd><p>The specification should, to the extent possible, minimize the
overhead involved in securing SOAP messages including content subject
to optimized transmission.</p></dd><dt class="label"><a id="r29" name="r29" />R29</dt><dd><p>A message, however serialized, must
be representable as a single SOAP message infoset.</p></dd><dt class="label"><a id="r33" name="r33" />R33</dt><dd><p>It must be possible to select more than one portion of the message for
optimization.</p></dd><dt class="label"><a id="r22" name="r22" />R22</dt><dd><p>Means must be provided in the infoset for optionally indicating the
media type of binary element content.</p></dd><dt class="label"><a id="r36" name="r36" />R36</dt><dd><p>It must be possible to encrypt the message or its portion(s), including non-XML data (e.g., binary data and XML fragments).</p></dd><dt class="label"><a id="r37" name="r37" />R37</dt><dd><p>It must be possible to sign the message or its portion(s), including non-XML data (e.g., binary data and XML fragments).</p></dd></dl></div><div class="div2">
<h3><a id="wire" name="wire" />4.3 Infoset Serialization Requirements</h3><p>This section lists requirements placed upon the serialization.
In them, the phrase "infoset parts" identifies
those parts of the Infoset that are targeted for optimization, while
"serialization parts" is used to refer to their corresponding
serialization artifacts "on the wire."  When unqualified "parts" is
used, the requirement applies to both senses.</p><dl><dt class="label"><a id="r1" name="r1" />R1</dt><dd><p>The spec must define at least one infoset serialization using
Multipart MIME, and possibly additional serializations.</p></dd><dt class="label"><a id="r2" name="r2" />R2</dt><dd><p>The serialization must be able to carry arbitrary data, including
non-XML data (e.g., binary data and XML fragments).</p></dd><dt class="label"><a id="r3" name="r3" />R3</dt><dd><p>The serialization should support efficient implementation of
parsing the physical representation to separate and identify its
constituent parts.</p></dd><dt class="label"><a id="r4" name="r4" />R4</dt><dd><p>The serialization should use a reasonably space-efficient
representation.</p></dd><dt class="label"><a id="r35" name="r35" />R35</dt><dd><p>The serialization should be designed to facilitate cooperation between
inbound and outbound bindings at a SOAP intermediary, resulting in
efficient relay of SOAP messages.</p></dd><dt class="label"><a id="r5" name="r5" />R5</dt><dd><p>The serialization should efficiently support the addition and
deletion of parts by intermediaries.</p></dd><dt class="label"><a id="r13" name="r13" />R13</dt><dd><p>The serialization must provide support for arbitrarily large
parts.</p></dd><dt class="label"><a id="r21" name="r21" />R21</dt><dd><p>The serialization should conveniently provide for the existence and
extension of metadata relating to the serialization, for example, the
version number of the serialization.</p></dd><dt class="label"><a id="r31" name="r31" />R31</dt><dd><p>The serialization should conveniently provide for the existence and
extension of metadata related to the serialization of individual
parts.</p></dd><dt class="label"><a id="r30" name="r30" />R30</dt><dd><p>The serialization must provide a facility for specifying length
metadata that is appropriate to meet likely buffering requirements of
receivers. The use of this facility is optional.</p></dd><dt class="label"><a id="r6" name="r6" />R6</dt><dd><p>Within the serialization, each part must be named by an absolute URI.</p></dd><dt class="label"><a id="r7" name="r7" />R7</dt><dd><p>The URI identification scheme must be robust under the addition and
deletion of parts -- i.e., it must not require that URIs to other
parts be altered, it must be relatively easy to avoid URI conflicts,
etc.</p></dd><dt class="label"><a id="r12" name="r12" />R12</dt><dd><p>The serialization part carrying the start of the primary envelope
document element must be easily locatable/identifiable.</p></dd></dl></div><div class="div2">
<h3><a id="binding" name="binding" />4.4 Binding Requirements</h3><dl><dt class="label"><a id="r34" name="r34" />R34</dt><dd><p>The specification will include either an enhancement to the existing
SOAP 1.2 HTTP binding or a new (but similar) binding.  The new or
extended binding will use the serialization to implement the
Attachment Feature.</p></dd><dt class="label"><a id="r17" name="r17" />R17</dt><dd><p>The specification must work with the SOAP 1.2 HTTP binding and
shouldn't unnecessarily preclude working with other bindings.</p></dd></dl></div></div><div class="div1">
<h2><a id="refs" name="refs" />5 References</h2><dl><dt class="label"><a id="ws-activity" name="ws-activity" />WS Activity</dt><dd>Web Services Activity.  (See http://www.w3.org/2002/ws/Activity.html.)</dd><dt class="label"><a id="XMLP-WG" name="XMLP-WG" />XMLP WG</dt><dd>XML
    	Protocol Working Group.  (See http://www.w3.org/2000/xp/Group/.)</dd><dt class="label"><a id="xmlp-charter" name="xmlp-charter" />XMLP Charter</dt><dd>XML Protocol Working Group Charter.  (See http://www.w3.org/2004/02/XML-Protocol-Charter.)</dd><dt class="label"><a id="xml-dist-app" name="xml-dist-app" />XMLP Archive</dt><dd>XML Protocol Discussion Archive.  (See http://lists.w3.org/Archives/Public/xml-dist-app/.)</dd><dt class="label"><a id="SOAP12-1" name="SOAP12-1" />SOAP Part 1</dt><dd>W3C Recommendation "SOAP
1.2 Part 1: Messaging Framework", Martin Gudgin, Mark Hadley,
Jean-Jacques Moreau, Henrik Frystyk Nielsen,
24 June 2003.  (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)</dd><dt class="label"><a id="SOAP12-2" name="SOAP12-2" />SOAP Part 2</dt><dd>W3C Recommendation "SOAP
1.2 Part 2: Adjuncts", Martin Gudgin, Mark Hadley,
Jean-Jacques Moreau, Henrik Frystyk Nielsen,
24 June 2003.  (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.)</dd><dt class="label"><a id="xmlp-abstract-attachment-feature" name="xmlp-abstract-attachment-feature" />Attachment Feature</dt><dd>W3C Working Draft "SOAP
1.2 Attachment Feature", Henrik Frystyk Nielsen, Hervé Ruellan,
14 August 2002.  (See http://www.w3.org/TR/2002/WD-soap12-af-20020814/.)</dd><dt class="label"><a id="swa" name="swa" />SwA</dt><dd>W3C Note "SOAP Messages with Attachments", John J.
Barton, Satish Thatte, and Henrik Frystyk Nielsen, 11 December
2000.  (See http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211.)</dd><dt class="label"><a id="paswa" name="paswa" />PASWA</dt><dd>"Proposed Infoset Addendum to SOAP Messages with
Attachments", Adam Bosworth, Don Box, Martin Gudgin, Mark Jones,
Franz-Josef Fritz, Amy Lewis, Jean-Jacques Moreau, Mark Nottingham,
David Orchard, Hervé Ruellan, Jeffrey Schlimmer, Volker Wiechers,
Version 0.61 Draft, 1 April 2003.  (See http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.)</dd><dt class="label"><a id="uc-summary" name="uc-summary" />UC Summary</dt><dd>"Attachments Use Cases Summary", David
Fallside, 17 September 2003.  (See http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0051.html.)</dd></dl></div></div><div class="back"><div class="div1">
<h2><a id="acknowledgments" name="acknowledgments" />A Acknowledgments (Non-Normative)</h2><p>This document is the work of the W3C XML Protocol Working Group
       <a href="#XMLP-WG">[XMLP WG]</a>.</p><p>Participants in the Working Group are (at the time of writing, and by
      alphabetical order): David Fallside (IBM),
Tony Graham (Sun Microsystems),
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
Marc Hadley (Sun Microsystems),
Gerd Hoelzing (SAP AG),
John Ibbotson (IBM),
Anish Karmarkar (Oracle),
Suresh Kodichath (IONA Technologies),
Yves Lafon (W3C),
Michael Mahan (Nokia),
Noah Mendelsohn (IBM, formerly of Lotus Development),
Jeff Mischkinsky (Oracle),
Jean-Jacques Moreau (Canon),
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
David Orchard (BEA Systems, formerly of Jamcracker),
Herve Ruellan (Canon),
Jeff Schlimmer (Microsoft Corporation),
Pete Wenzel (SeeBeyond),
Volker Wiechers (SAP AG).
</p><p>Previous participants were: Yasser alSafadi (Philips Research),
Bill Anderson (Xerox),
Vidur Apparao (Netscape),
Camilo Arbelaez (webMethods),
Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems),
Philippe Bedu (EDF (Electricite De France)),
Olivier Boudeville (EDF (Electricite De France)),
Carine Bournez (W3C),
Don Box (Microsoft Corporation, formerly of DevelopMentor),
Tom Breuel (Xerox),
Dick Brooks (Group 8760),
Winston Bumpus (Novell, Inc.),
David Burdett (Commerce One),
Charles Campbell (Informix Software),
Alex Ceponkus (Bowstreet),
Michael Champion (Software AG),
David Chappell (Sonic Software),
Miles Chaston (Epicentric),
David Clay (Oracle),
David Cleary (Progress Software),
Dave Cleary (webMethods),
Ugo Corda (Xerox),
Paul Cotton (Microsoft Corporation),
Fransisco Cubera (IBM),
Jim d'Augustine (Excelon Corporation),
Ron Daniel (Interwoven),
Glen Daniels (Macromedia),
Doug Davis (IBM),
Ray Denenberg (Library of Congress),
Paul Denning (MITRE Corporation),
Frank DeRose (TIBCO Software, Inc.),
Mike Dierken (DataChannel),
Andrew Eisenberg (Progress Software),
Brian Eisenberg (DataChannel),
Colleen Evans (Sonic Software),
John Evdemon (XMLSolutions),
David Ezell (Hewlett Packard),
James Falek (TIBCO Software, Inc.),
Eric Fedok (Active Data Exchange),
Chris Ferris (Sun Microsystems),
Daniela Florescu (Propel),
Dan Frantz (BEA Systems),
Michael Freeman (Engenia Software),
Dietmar Gaertner (Software AG),
Scott Golubock (Epicentric),
Mike Greenberg (IONA Technologies),
Rich Greenfield (Library of Congress),
Hugo Haas (W3C),
Mark Hale (Interwoven),
Randy Hall (Intel),
Bjoern Heckel (Epicentric),
Frederick Hirsch (Zolera Systems),
Erin Hoffmann (Tradia Inc.),
Steve Hole (MessagingDirect Ltd.),
Mary Holstege (Calico Commerce),
Jim Hughes (Fujitsu Limited),
Oisin Hurley (IONA Technologies),
Yin-Leng Husband (Hewlett Packard, formerly of Compaq),
Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.),
Scott Isaacson (Novell, Inc.),
Kazunori Iwasa (Fujitsu Limited),
Murali Janakiraman (Rogue Wave),
Mario Jeckle (DaimlerChrysler Research and Technology),
Eric Jenkins (Engenia Software),
Mark Jones (AT&amp;T),
Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software),
Richard Koo (Vitria Technology Inc.),
Jacek Kopecky (Systinet),
Alan Kropp (Epicentric),
Julian Kumar (Epicentric),
Peter Lecuyer (Progress Software),
Tony Lee (Vitria Technology Inc.),
Michah Lerner (AT&amp;T),
Bob Lojek (Intalio Inc.),
Henry Lowe (OMG),
Brad Lund (Intel),
Matthew MacKenzie (XMLGlobal Technologies),
Murray Maloney (Commerce One),
Richard Martin (Active Data Exchange),
Alex Milowski (Lexica),
Kevin Mitchell (XMLSolutions),
Nilo Mitra (Ericsson),
Ed Mooney (Sun Microsystems),
Dean Moses (Epicentric),
Highland Mary Mountain (Intel),
Don Mullen (TIBCO Software, Inc.),
Rekha Nagarajan (Calico Commerce),
Raj Nair (Cisco Systems),
Masahiko Narita (Fujitsu Limited),
Mark Needleman (Data Research Associates),
Art Nevarez (Novell, Inc.),
Eric Newcomer (IONA Technologies),
Henrik Nielsen (Microsoft Corporation),
Conleth O'Connell (Vignette),
Kevin Perkins (Compaq),
Jags Ramnaryan (BEA Systems),
Andreas Riegg (DaimlerChrysler Research and Technology),
Vilhelm Rosenqvist (NCR),
Marwan Sabbouh (MITRE Corporation),
Waqar Sadiq (Vitria Technology Inc.),
Rich Salz (Zolera Systems),
Krishna Sankar (Cisco Systems),
George Scott (Tradia Inc.),
Shane Sesta (Active Data Exchange),
Lew Shannon (NCR),
John-Paul Sicotte (MessagingDirect Ltd.),
Miroslav Simek (Systinet),
Simeon Simeonov (Macromedia),
Aaron Skonnard (DevelopMentor),
Nick Smilonich (Unisys),
Seumas Soltysik (IONA Technologies),
Soumitro Tagore (Informix Software),
James Tauber (Bowstreet),
Anne Thomas Manes (Sun Microsystems),
Lynne Thompson (Unisys),
Patrick Thompson (Rogue Wave),
Jim Trezzo (Oracle),
Asir Vedamuthu (webMethods),
Randy Waldrop (WebMethods),
Fred Waskiewicz (OMG),
David Webber (XMLGlobal Technologies),
Ray Whitmer (Netscape),
Stuart Williams (Hewlett Packard),
Yan Xu (DataChannel),
Amr Yassin (Philips Research),
Susan Yee (Active Data Exchange),
Jin Yu (MartSoft Corp.).
</p><p>The editors thank the present and past members of the Attachments
Requirements Task Force (ARTF) for their contribution to this document:
David Fallside, Tony Graham, Martin Gudgin, Marc Hadley, Mark Jones,
Anish Karmarkar, Noah Mendelsohn, Mark Nottingham, Hervé Ruellan,
and Jeffrey Schlimmer.</p><p>The people who have contributed to discussions on <a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>
<a href="#xml-dist-app">[XMLP Archive]</a> are also gratefully acknowledged.</p></div><div class="div1">
<h2><a id="changelog" name="changelog" />B Change Log (Non-Normative)</h2><a id="tablelog" name="tablelog" /><table border="1"><thead><tr><th>Who</th><th>When</th><th>What</th></tr></thead><tbody><tr><td>TG</td><td>20040222</td><td>Removed R26 since it applies
	    to UC12, and UC12 is out of scope.</td></tr><tr><td>TG</td><td>20031029</td><td>Changed 'Preamble' to
	    'Introduction'.  Added references to SOAP 1.2.</td></tr><tr><td>ASK</td><td>20031023</td><td>Removed MAJ's ednote. Added UC6</td></tr><tr><td>ASK</td><td>20031016</td><td>Added UC12, changed UC9&amp;UC10 to reflect plurality of binary objects, removed three ED notes, added current&amp;previous members of WG</td></tr><tr><td>ASK</td><td>20031007</td><td>Added requirements derived from UC-4</td></tr><tr><td>TG</td><td>20030925</td><td>Changed to XML markup.  Added
use cases. Moved 'Considerations' section to inside 'Requirements' section.</td></tr><tr><td>MAJ</td><td>20030825</td><td>Changed title, updated status
 	    for WD, added preamble to doc and section 3.2</td></tr></tbody></table></div></div></body></html>