Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document describes an abstract feature and a concrete implementation of it for optimizing the transmission and/or wire format of SOAP messages. The concrete implementation relies on the [XOP] format for carrying SOAP messages.
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 W3C technical reports index at http://www.w3.org/TR/.
This document is theW3CLastCallWorkinga Candidate Recommendation of the DraftSOAPMessageTransmissionOptimizationMechanismdocument.W3C.
This document has been produced by the
XML Protocol Working Group It(WG),which(WG)
as part of the W3C
Web Services Activity.
isDiscussionPublication as a Candidate Recommendation 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 oftakesplaceonthepublicxml-dist-app@w3.orgmailinglist(publicarchive)undertheemailcommunicationas other than work in progress.
rules
This document is based upon the
XMLSOAP Message Transmission Optimization Mechanism
Last Call Working ProtocolGroupCharter.Draft published on Commentsthisdocumentarewelcome.Sendthembefore8 June 292004.
Changes between these two versions are described in a diff document.
2004
The public is invited to send comments to the public mailing list
xmlp-comments@w3.org(publicxmlp-comments@w3.org
(Archive).
archive)
NotethatallThe WG is soliciting implementation reports on this draft until at least
15 September 2004. All issues against this document are documented in the outstandingWorkingGroupLastWG's
Candidate Recommendation Issues List. CallWhen implementations of this
document's important features are demonstrated to be interoperable between
2 or more different implementations, and the IffeedbackWG responds formally to all
issues against this ondocumentisdocument, then the WG plans to submit it for
consideration as a W3C positive,Proposed Recommendation. Records of the
interoperation of this document's features are recorded on the WG's
Implementation Summary of Optimizations webpage.
Candidate
This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. 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 W3C Patent Policy. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
| |
The current XML Schema references |
1 Introduction
1.1 Notational Conventions
1.2 Relation to other specifications
2 Abstract SOAP Transmission Optimization Feature
2.1 Introduction
2.2 Abstract SOAP Transmission Optimization Feature Name
2.3 Abstract SOAP Transmission Optimization Feature Processing
2.3.1 Sending a message
2.3.2 Receiving a message
2.3.3 Intermediaries
2.3.4 Binding Optimizations at Intermediaries
3 An Optimized MIME Multipart/Related Serialization of SOAP
Messages
3.1 Introduction
3.2 Serialization of a SOAP message
3.3 Deserialization of a SOAP message
4 HTTP SOAP Transmission Optimization Feature
4.1 Introduction
4.2 HTTP SOAP Transmission Optimization Feature Name
4.3 Implementation
4.3.1 Sending a SOAP message
4.3.1.1 Init
4.3.2 Receiving a SOAP message
A Theapplication/soap_xop+xmlMediaType A.1Introduction A.2RegistrationReferencesB
B Acknowledgements (Non-Normative)
The first part of this document (2 Abstract SOAP Transmission Optimization Feature) describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message ([SOAP Part 1]) by selectively encoding portions of the message, while still presenting an XML Infoset to the SOAP application.
TheUse of the Abstract SOAP 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 pass-through of optimized data contained
within headers or bodies relayed by an intermediary (see 2.3.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.
usage
The second part (3 An Optimized MIME Multipart/Related Serialization of SOAP Messages) describes an Optimized MIME Multipart/Related Serialization of SOAP Messages implementing the Abstract SOAP Transmission Optimization Feature in a binding independent way. This implementation relies on the [XOP] format.
The third part (4 HTTP SOAP Transmission Optimization Feature) uses this Optimized MIME Multipart/Related Serialization of SOAP Messages for describing an implementation of the Abstract Transmission Optimization Feature for the SOAP 1.2 HTTP binding (see [SOAP Part 2] 7. SOAP HTTP Binding).
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 [Prefixes and Namespaces used in this specification.]. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see XML Infoset [XML InfoSet]).
Prefix | Namespace |
---|---|
Notes | |
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. | |
xop | |
A non-normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the
| |
rep | |
A normative XML Schema [XML Schema Part 1], [XML Schema Part 2] document for the
| |
xs | "http://www.w3.org/2001/XMLSchema" |
The namespace of XML Schema data types (see [XML Schema Part 2]). |
The 4 HTTP SOAP Transmission Optimization Feature (which is an implementation of the 2 Abstract SOAP Transmission Optimization Feature for the SOAP 1.2 HTTP binding) is intended to enhance the SOAP HTTP binding described in [SOAP Part 2] 7. SOAP HTTP Binding or an updated version of it.
This document along with [XOP]
and [SOAP Representation Header] has been produced in conjunction
with the development of requirements
embodied in the requirements,requirements[SOAP documentAttachmentRequirements]andthespecificationdescribedhereinfulfillsthoseOptimized Serialization Use Cases and Requirements] document.
requirements.
The Abstract SOAP Transmission Optimization Feature enables SOAP bindings
to optimize the transmission and/or wire format of a SOAP message by
selectively encoding portions of the message, whilst still presenting
an XML Infoset to the SOAP application. Optimization is available
only for element content that is in a canonical lexical
representation of the xs:base64Binary
data type (see
[XML Schema Part 2] 3.2.16
base64Binary).
Note: because there is a one-to-one correspondence between such
canonical forms and values in the value space of
xs:base64Binary
, MTOM implementations typically optimize
by transmitting a compact representation of the value in place of the
less compact character sequence. At the receiver, the character form
can be reconstructed if necessary.
Consistent with the requirement that a SOAP binding transmit the Envelope Infoset intact, implementations of this feature MUST NOT substitute canonical for non-canonical representations, or make other changes to optimized element content.
This Abstract SOAP Transmission Optimization Feature is identified by the URI:
"http://www.w3.org/2004/08/soap/features/abstract-optimization".
"http://www.w3.org/2003/06/soap/features/abstract-optimization".
When sending a SOAP Message, if the Abstract Transmission
Optimization Feature is used in combination with the SOAP
Request-Response Message Exchange Pattern ([SOAP Part 2] 6.2
SOAP Request-Response Message Exchange Pattern) or the
SOAP Response Message Exchange Pattern ([SOAP Part 2] 6.3 SOAP
Response Message Exchange Pattern), the
http://www.w3.org/2003/05/soap/mep/OutboundMessage
property is the Infoset of the SOAP Message to be sent. Similar
rules should be applied for other MEPs, as appropriate.
One purpose of the Abstract SOAP Transmission Optimization Feature is to
optimize the transmission of base64 encoded data. To be optimized,
the characters comprising the [children] of an element
information item MUST be in the canonical form of
xs:base64Binary
(see [XML Schema Part 2]
3.2.16
base64Binary) and MUST NOT contain any whitespace
characters, preceding, inline with or following the non-whitespace
content.
not
Note: the means of identifying element information
items that contain base64 encoded data in
canonical lexical form are implementation-dependent. Some
implementations can identify such element information
items by construction (e.g., because a certain API may
create only canonical forms); others may check the characters prior
to sending, others may rely on information in the description such
as the presence and/or value of the sending.xmlmime:expectedMediaType
schema annotation (see [Assigning Media Types to Binary Data in XML]), if a schema is available.
Because of the need to exactly preserve the characters
in the transmitted Infoset, non-canonical representations MUST NOT
be optimized by implementations of this feature.
optimized.
When receiving a SOAP message optimized using an implementation of the Abstract SOAP Transmission Optimization Feature, a SOAP node SHOULD generate a fault if it does not support the implementation used or the Abstract SOAP Transmission Optimization Feature.
Upon reception of an optimized SOAP message, the receiving node MUST reconstruct an Envelope Infoset from the optimized SOAP message. Then, the receiving node MUST perform SOAP processing on the reconstructed Infoset (see [SOAP Part 1] 2. SOAP Processing Model). In all cases, the received Infoset MUST be exactly the same as that transmitted by the sender.
ReceiversMUSTNOT,forexample,convertnon-canonicallexicalrepresentationstoImplementations are free to reconstruct only those portions
actually needed for processing, or to present information from the
message in a form convenient for efficient processing. For example,
a value sent in an optimized form (e.g., binary) MAY be made
available in that form as well as in the base64 encoded character
form.
canonical.
When this feature is used in combination with the SOAP
Request-Response Message Exchange Pattern ([SOAP Part 2] 6.2
SOAP Request-Response Message Exchange Pattern) or the
SOAP Response Message Exchange Pattern ([SOAP Part 2] 6.3 SOAP
Response Message Exchange Pattern), the Infoset
contained in the
http://www.w3.org/2003/05/soap/mep/InboundMessage
property is the Infoset of the reconstructed SOAP Envelope. Similar
rules should be applied for other MEPs, as appropriate.
TheUse of the Abstract SOAP 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. The section 2.3.4 Binding Optimizations at Intermediaries details the
means by which certain optimizations can be performed by bindings
at intermediaries.
usage
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.3.2 Receiving a message) and those related to the usage of an
implementation of the Abstract SOAP Transmission Optimization Feature
when sending the message (see 2.3.1 Sending a message). In
particular, it MUST follow the rules for relaying SOAP messages (see
[SOAP Part 1] 2.7
Relaying SOAP Messages).
addition,
As described in [SOAP Part 1] 2.7 Relaying SOAP Messages, a SOAP intermediary may be called upon 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 SOAP 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.
Note: a consequence of this architecture 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 non-optimized forms in all cases. Other bindings may be capable of optimization, but may or may not choose to optimize 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.
The Optimized MIME Multipart/Related Serialization expands upon the Abstract SOAP Transmission Optimization Feature by describing parts of an implementation of this feature using the [XOP] format as its basis. This specification does not describe a full implementation but is intended to provide support for building a full implementation of the Abstract SOAP Transmission Optimization Feature. In particular, this specification does not specify the use of any transport for the SOAP message. A full implementation based on this specification is described in 4.2 HTTP SOAP Transmission Optimization Feature Name.
The Optimized MIME Multipart/Related Serialization provides the basis for an implementation of the Abstract Transmission Optimization Feature by describing how to serialize a SOAP envelope in an optimized way, using the [XOP] format and a MIME Multipart/Related packaging ([RFC 2387]).
More specifically, the SOAP envelope Infoset is transmitted as a MIME Multipart/Related XOP Package (see [XOP], 4.1 MIME Multipart/Related XOP Packages). Any W3C recommendation-level version of XML is allowed for storing the XOP Infoset created from the SOAP envelope Infoset into the MIME Multipart/Related XOP Package, however, note that the SOAP envelope Infoset MUST be serializable as XML 1.0.
When sending a SOAP message using the MIME Multipart/Related Serialization, the SOAP envelope Infoset is serialized as specified in [XOP] 3.1 Creating XOP packages. Specifically:
The result is a MIME Multipart/Related XOP package (see [XOP]): one body part, the root, containing an XML representation of the modified SOAP envelope, with an additional part used to contain the binary representation of each element that was optimized.
When receiving a SOAP message using this Optimized MIME Multipart/Related Serialization, the SOAP Envelope Infoset is reconstructed from the MIME Multipart/Related XOP Package by performing the processing specified in [XOP] 3.2 Interpreting XOP packages.
Note: conventions or error reporting mechanisms to be used in processing packages that incorrectly purport to be XOP Packages containing a SOAP Envelope are beyond the scope of this specification.
The HTTP SOAP Transmission Optimization Feature is a binding-level feature implementing the Abstract SOAP Transmission Optimization Feature in an HTTP binding. The basis of this HTTP SOAP Transmission Optimization Feature is the Optimized MIME Multipart/Related Serialization described in 3 An Optimized MIME Multipart/Related Serialization of SOAP Messages.
This HTTP SOAP Transmission Optimization Feature builds upon the current HTTP binding (see [SOAP Part 2] 7. SOAP HTTP Binding), enhancing it with the support of the Abstract SOAP Transmission Optimization Feature. In all aspects not described in this section, the rules of the HTTP binding are not modified.
This HTTP SOAP Transmission Optimization Feature is identified by the URI:
"http://www.w3.org/2004/08/soap/features/http-optimization".
"http://www.w3.org/2003/06/soap/features/http-optimization".
The HTTP SOAP Transmission Optimization Feature uses the Optimized MIME Multipart/Related Serialization (see 3 An Optimized MIME Multipart/Related Serialization of SOAP Messages) for implementing the Abstract SOAP Transmission Optimization Feature. On the sending side, this feature serializes the SOAP message as described in 3.2 Serialization of a SOAP message and puts the resulting MIME Multipart/Related XOP Package in the HTTP body. On the receiving side, this feature extracts the MIME Multipart/Related XOP Package from the HTTP body and deserializes as described in 3.3 Deserialization of a SOAP message.
When sending a SOAP message, the HTTP SOAP Transmission Optimization Feature changes the behavior of [SOAP Part 2] 7. SOAP HTTP Binding. This section describes the perturbations to [SOAP Part 2] 7.5.1 Behavior of Requesting SOAP Node that result from use of the HTTP SOAP Transmission Optimization Feature. Only those aspects described below differ from the existing operation of the HTTP binding, all other aspects of its operation remaining unchanged.
In the "Init" state, a HTTP request is formulated and transmission of the request is initiated. When using the HTTP SOAP Transmission Optimization Feature, the formulation of the request differs from [SOAP Part 2] 7.5.1.1 Init as shown in [HTTP Request Fields].
Field | Value |
---|---|
Content-Type header field | |
HTTP entity body | SOAP message serialized as described in |
The XOP package is constructed as described in 3 An Optimized MIME Multipart/Related Serialization of SOAP Messages with the following restriction:
The XOP Infoset MUST be serialized as
in the root part of the
application/xop+xmlapplication/soap_xop+xmlpackage per Section 5 of [XOP].
package.
Each optimized Node MUST generate exactly one
extracted binary part in the resulting package, i.e.,
extracted binary parts MUST NOT be referenced by more than
one xop:Include
in the SOAP message part.
Each MIME part that is refered to by xop:Include
MUST have a Content-Transfer-Encoding header field.
Content-Tranfer-Encoding
Note: this does not preclude the MIME Multipart/Related package
from including additional parts not referenced by a
withxop:Include
element. Such additional parts are not part of
the SOAP message Infoset and are not included in the SOAP
processing model.
.
Implementations of this binding MUST enforce the restriction that
XOP is not to be used with Infosets that contain element
information items of name xop:Include
(see
[XOP] 3.
XOP Infosets Constructs). In any case where a SOAP
envelope containing such an element information item
is to be sent, the binding MUST do one of the following:
application/soap+xml
media type
or any other suitable media type, i.e., send the SOAP envelope
without using the HTTP SOAP Transmission Optimization Feature.
Editorial note: HR | |
Request for comments:
The binding framework of the SOAP recommendation provides
that "the minimum responsibility of a binding in transmitting
a message is to specify the means by which the SOAP message
Infoset is transferred to and reconstituted by the binding at
the receiving SOAP node and to specify the manner in which
the transmission of the envelope is effected using the
facilities of the underlying protocol." (see [SOAP Part 1] 4.2 Binding
Framework). Although illegal as input to XOP
encoding, elements named |
Note that such SOAP envelopes could in principle arise either from data created locally at the sending node or in data relayed at an intermediary. Bindings are responsible for checking all such input as necessary to ensure that the rule just stated is enforced.
When receiving a SOAP message, an implementation of the SOAP HTTP
Binding (see [SOAP Part 2]) will determine whether
the HTTP SOAP Transmission Optimization Feature is used by checking the
presence of the
media type (see
application/xop+xmlapplication/soap_xop+xml[XOP] Section 5.1). If the media type of the HTTP message is "multipart/related"
and the media type of the root part of the MIME Multipart/Related
package is ???).
, and the start-info parameter
indicates a content type of "application/soap+xml" then the received
SOAP message was transmitted using the HTTP SOAP Transmission
Optimization Feature and MUST be processed accordingly.
application/xop+xmlapplication/soap_xop+xml
The HTTP SOAP Transmission Optimization Feature changes the behavior of
[SOAP Part 2] 7. SOAP
HTTP Binding for the reception of a SOAP message. The
remainingofthissectiondescribesperturbations to [SOAP Part 2] 7.5.2
Behavior of Responding SOAP Node that result from use
of the HTTP SOAP Transmission Optimization theFeature.OnlythoseaspectsdescribedbelowdifferfromtheexistingoperationoftheHTTPbinding,allotheraspectsofitsoperationremainingFeature are as follows:
unchanged.
When making an abstraction of the request message available in
http://www.w3.org/2003/05/soap/mep/InboundMessage
, the
HTTP Binding MUST reconstruct the SOAP Envelope Infoset as
described in 3.3 Deserialization of a SOAP message.
ATheapplication/soap_xop+xmlMediaTypeA.1IntroductionSOAPversion1.2([SOAPPart1]and[SOAPPart2])isalightweightprotocolintendedforexchangeofstructuredinformationbetweenpeersinadecentralized,distributedenvironment.ItdefinesanextensiblemessagingframeworkthatcontainsamessageconstructbasedonXMLtechnologiesthatcanbeexchangedoveravarietyofunderlyingprotocols.TheXML-binaryOptimizedPackagingMechanism[XOP]isanalternateserializationoftheXMLInfoset,intendedtomakeprocessingandrepresentationofcertaintypesofcontent(specifically,thatwhichisbase64-encoded)moreefficient.Suchserializations,whenfree-standing,arecalledXOPPackages;theportionoftheXOPPackagethatrepresentsthestructureandnon-optimizedcontentoftheInfosetarecalledXOPDocuments,andareserializedasXML.Thisappendixdefinesthemediatypeapplication/soap_xop+xmlwhichcanbeusedtoidentifySOAP1.2messageenvelopesthathavebeenserializedasXOPDocumentsusingXML1.0([XML1.0]).Theapplication/soap_xop+xmlmediatypeexplicitlyidentifiestheXOPDocumentportionofaSOAP1.2messageenvelope,serializedasXML1.0.Inotherwords,itidentifiestheserializedXMLaftertheextractionofanycontentintotheXOPPackage;itdoesnotidentifythepackageitself.XOPDocumentsnotserializedasXML1.0orrepresentingmessageenvelopeswithadifferentSOAPnamespaceversionMUSTNOTuseit.A.2RegistrationMIMEmediatypename:application.MIMEsubtypename:soap_xop+xmlRequiredparameters:noneOptionalparameters:"charset":Thisparameterhasidenticalsemanticstothecharsetparameteroftheapplication/xmlmediatypeasspecifiedinRFC3023[RFC3023]."action":ThisoptionalparametercanbeusedtospecifytheURIthatidentifiestheintentofthemessage.InSOAP1.2,itservesasimilarpurposeastheSOAPActionHTTPheaderfielddidinSOAP1.1.Namely,itsvalueidentifiestheintentofthemessage.ThevalueoftheactionparameterisanabsoluteURI-referenceasdefinedbyRFC2396[RFC2396].SOAPplacesnorestrictionsonthespecificityoftheURIorthatitisresolvable.AlthoughthepurposeoftheactionparameteristoindicatetheintentoftheSOAPmessagethereisnomechanismforautomaticallycomputingthevaluebasedontheSOAPenvelope.Inotherwords,thevaluehastobedeterminedoutofband.Itisrecommendedthatthesamevaluebeusedtoidentifysetsofmessagetypesthatarelogicallyconnectedinsomemanner,forexamplepartofthesame"service".ItisstronglyRECOMMENDEDthattheURIbegloballyuniqueandstableovertime.ThepresenceandcontentoftheactionparameterMAYbeusedbyserverssuchasfirewallstoappropriatelyfilterSOAPmessagesanditmaybeusedbyserverstofacilitatedispatchingofSOAPmessagestointernalmessagehandlersetc.ItSHOULDNOTbeusedasaninsecureformofaccessauthorization.UseoftheactionparameterisOPTIONAL.SOAPReceiversMAYuseitasahinttooptimizeprocessing,butSHOULDNOTrequireitspresenceinordertooperate.Encodingconsiderations:Identicaltothoseofapplication/xmlasdescribedinRFC3023[RFC3023],section3.2,asappliedtotheSOAPenvelopeInfoset.Securityconsiderations:BecauseSOAPcancarryapplicationdefineddatawhosesemanticsisindependentfromthatofanyMIMEwrapper(orcontextwithinwhichtheMIMEwrapperisused),oneshouldnotexpecttobeabletounderstandthesemanticsoftheSOAPmessagebasedonthesemanticsoftheMIMEwrapperalone.Therefore,wheneverusingtheapplication/soap_xop+xmlmediatype,itisstronglyRECOMMENDEDthatthesecurityimplicationsofthecontextwithinwhichtheSOAPmessageisusedisfullyunderstood.ThesecurityimplicationsarelikelytoinvolveboththespecificSOAPbindingtoanunderlyingprotocolaswellastheapplication-definedAll other aspects of the semanticsdatacarriedintheSOAPmessage(thoughonemustbecarefulwhendoingthis,asdiscussedinSOAP1.2Part1[SOAPPart1],7.3.1BindingtoApplication-SpecificProtocols.Also,seeSOAP1.2Part1[SOAPPart1],7.SecurityConsiderations.Inaddition,asthismediatypeusesthe"+xml"convention,itsharesthesamesecurityconsiderationsasdescribedinRFC3023[RFC3023],section10.Interoperabilityconsiderations:Therearenoknowninteroperabilityissues.Publishedspecification:SOAP1.2Part1[SOAPPart1],SOAP1.2Part2,[SOAPPart2],andXOP[XOP].Applicationswhichusethismediatype:Noknownapplicationscurrentlyusethismediatype.Additionalinformation:Fileextension:SOAPmessagesarenotrequiredorexpectedtobestoredasfiles.Fragmentidentifiers:Identicaltothatofapplication/xmlasdescribedinRFC3023[RFC3023],section5.BaseURI:AsspecifiedinRFC3023[RFC3023],section6.AlsoseeSOAP1.2Part1[SOAPPart1],6.UseofURIsinSOAP.MacintoshFileTypecode:TEXTPersonandemailaddresstocontactforfurtherinformation:MarkNottingham<mnot@pobox.com>Intendedusage:COMMONAuthor/Changecontroller:TheSOAP1.2specificationsetisaworkoperation of the productWorldWideWebConsortium'sXMLProtocolWorkingGroup.TheW3Chaschangecontroloverthesespecifications.HTTP binding remain unchanged.
B
This specification is the work of the W3C XML Protocol Working Group.
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).
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&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&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.).
The people who have contributed to discussions on xml-dist-app@w3.org are also gratefully acknowledged.