index.html
37.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
<?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 1.2 Attachment Feature</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-WG-NOTE.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 1.2 Attachment Feature</h1>
<h2><a id="w3c-doctype" name="w3c-doctype" />W3C Working Group Note 8 June 2004</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/">http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/</a>
</dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/soap12-af/">
http://www.w3.org/TR/soap12-af/</a>
</dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2002/WD-soap12-af-20020924/">http://www.w3.org/TR/2002/WD-soap12-af-20020924/</a>
</dd><dt>Editors:</dt><dd>Henrik Frystyk Nielsen, Microsoft</dd><dd>Hervé Ruellan, Canon</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 defines a SOAP feature that represents an abstract model
for SOAP attachments. It provides the basis for the creation of SOAP
bindings that transmit such attachments along with a SOAP envelope, and
provides for reference of those attachments from the envelope. SOAP
attachments are described using the notion of a compound document
structure consisting of a primary SOAP message part and zero or more
related documents parts known as attachments.</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>This document is the work of the <a href="http://www.w3.org/2000/xp/Group/">W3C XML Protocol Working Group</a> (WG). The
Attachment Feature document has been superceded by the <a href="http://www.w3.org/TR/soap12-mtom/">SOAP Message
Transmission Optimization Mechanism</a> document which describes
attachment related features along with some implementation details. The
XMLP WG does not intend to do any further work on the Attachment Feature
document.</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 (<a href="http://lists.w3.org/Archives/Public/xml-dist-app/">public archive</a>) under the email
communication rules in the <a href="http://www.w3.org/2004/02/XML-Protocol-Charter">
XML Protocol Working Group
Charter </a>.</p><p>
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>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 Group Note 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="#intro">Introduction</a><br />
1.1 <a href="#notations">Notational Conventions</a><br />
1.2 <a href="#conformance">Conformance</a><br />
2 <a href="#name">SOAP Feature Name</a><br />
3 <a href="#terminology">Terminology</a><br />
4 <a href="#model">Compound SOAP Structure Model</a><br />
5 <a href="#properties">Attachment Feature properties</a><br />
5.1 <a href="#sendingCompound">Sending a compound SOAP structure</a><br />
5.2 <a href="#receivingCompound">Receiving a compound SOAP structure</a><br />
6 <a href="#implementation">Implementation</a><br />
7 <a href="#intermediaries">Intermediaries</a><br />
8 <a href="#i18n">Internationalization Considerations</a><br />
9 <a href="#security">Security Considerations</a><br />
10 <a href="#iana">IANA Considerations</a><br />
11 <a href="#refs">References</a><br />
11.1 <a href="#refs-norm">Normative References</a><br />
11.2 <a href="#N102CD">Informative References</a><br />
</p>
<h3><a id="appendices" name="appendices" />Appendices</h3><p class="toc">A <a href="#contributors">Contributors</a><br />
B <a href="#History">History</a><br />
B.1 <a href="#N102F9">5 december 2002</a><br />
B.2 <a href="#N10303">4 november 2002</a><br />
B.3 <a href="#N10324">31 october 2002</a><br />
B.4 <a href="#N10339">31 July 2002</a><br />
B.5 <a href="#N10367">30 July 2002</a><br />
B.6 <a href="#N1038C">22 July 2002</a><br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a id="intro" name="intro" />1 Introduction</h2><p>SOAP 1.2 part 1 (see <a href="#W3C.WD-soap-part1">[SOAP Part 1]</a>) provides a
flexible and extensible envelope for describing structured information
intended for exchange between SOAP nodes. Even though SOAP 1.2 is
described in terms of <a href="#W3C.REC-xml-infoset">[XML Infoset]</a>, it is expected that <a href="#W3C.REC-xml">[XML 1.0]</a> will be a widely used
representation for SOAP data.</p><p>The following problems can arise when using such an <a href="#W3C.REC-xml">[XML 1.0]</a> representation for SOAP data:</p><ol class="enumar"><li><p>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 as defined by <a href="#RFC2045">[RFC 2045]</a>) is often significant both in
terms of bytes added because of the encoding as well as processor
overhead performing the encoding/decoding.</p></li><li><p>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.</p></li><li><p>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.</p></li></ol><p>The compound message structures provided by this specification MAY be
used to create SOAP bindings, or other specifications to be used by
bindings, that avoid some or all such problems.</p><p>The purpose of this specification is not to define an actual
representation of SOAP attachments but rather to define an abstract
SOAP 1.2 feature which can be used as the basis for defining SOAP
bindings that support the transmission of messages with attachments.
The feature describes characteristics common to all such
implementations.</p><div class="div2">
<h3><a id="notations" name="notations" />1.1 Notational Conventions</h3><p>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 <a href="#RFC2119">[RFC 2119]</a>.</p></div><div class="div2">
<h3><a id="conformance" name="conformance" />1.2 Conformance</h3><p>This document describes a SOAP attachment feature which is an
abstract model, and conformance is a property of SOAP binding
specifications or of SOAP modules that use this model.
</p><p>A SOAP binding specification or a SOAP module using this model is conformant if it follows all the requirements of this specification (see in particular <a href="#implementation"><b>6 Implementation</b></a>).
</p></div></div><div class="div1">
<h2><a id="name" name="name" />2 SOAP Feature Name</h2><p>This Attachment Feature is identified by the URI</p><p> (see <a href="#W3C.WD-soap-part1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624//#transpbindframew">SOAP Protocol Binding Framework</a>)</p><p>:</p><ul><li><p>
"http://www.w3.org/2002/06/soap/features/attachment" .
</p></li></ul></div><div class="div1">
<h2><a id="terminology" name="terminology" />3 Terminology</h2><dl><dt class="label">Compound SOAP structure</dt><dd><p> A compound SOAP structure consists of a primary SOAP message
part and zero or more related secondary parts.</p></dd><dt class="label">Primary SOAP message part</dt><dd><p>A SOAP message that provides the processing context for the
compound SOAP structure as a whole including the secondary
parts.</p></dd><dt class="label">Secondary Part</dt><dd><p>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. Secondary parts are
informally referred to as attachments.</p></dd></dl><p>Note: the use of the term "part" in this specification is
independent of its use in other specifications and should not be
assumed to be identical.
</p></div><div class="div1">
<h2><a id="model" name="model" />4 Compound SOAP Structure Model</h2><p>Throughout this document, the components of a compound document
structure are called parts. Accordingly, 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.</p><p>For example 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.</p><p>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 semantic relationship between the primary SOAP message
part and secondary parts, or between secondary parts.</p><p>It is important to note that the compound SOAP structure model does
not modify or supersede the message envelope 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).</p><p>Each part is identified by one or more URIs (typically one) that can
be used to reference it from other parts. The URI(s) identifying a part
can be of any URI scheme. It is RECOMMENDED that only IANA registered
URI schemes be used.</p><p>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).</p></div><div class="div1">
<h2><a id="properties" name="properties" />5 Attachment Feature properties</h2><p>
The Attachment Feature defines a set of properties described
in Property definition for the Attachment FeatureProperty NameProperty Description
SOAPMessage
An abstract structure that represents the primary SOAP
message part of the compound SOAP structure.
SecondaryPartBag
An abstract structure that represents the compound SOAP
structure's secondary part(s). This structure is a bag that
contains representations of each of the compound SOAP
structure's secondary part(s). A secondary part representation
can be a URI referencing this secondary part, an abstract
structure representing the secondary part itself, or both.
.</p><p>
Note: the base URI for all the properties defined in this section is
<code>http://www.w3.org/2002/06/soap/features/attachment</code>. In this section, property names are sometimes given using a URI relative to this base URI.
</p><div id="tabprops"><table border="1"><caption>Property definition for the Attachment Feature</caption><tbody><tr><th>Property Name</th><th>Property Description</th></tr><tr><td>
<code>SOAPMessage</code>
</td><td>An abstract structure that represents the primary SOAP
message part of the compound SOAP structure.
</td></tr><tr><td>
<code>SecondaryPartBag</code>
</td><td>An abstract structure that represents the compound SOAP
structure's secondary part(s). This structure is a bag that
contains representations of each of the compound SOAP
structure's secondary part(s). A secondary part representation
can be a URI referencing this secondary part, an abstract
structure representing the secondary part itself, or both.
</td></tr></tbody></table></div><p>Both these properties are instantiated inside the scope of a message
exchange context. If several messages are exchanged inside the scope of
this message exchange context, each instantiation of those properties
is linked to a particular message.</p><p>Note: the </p><p><code>http://www.w3.org/2002/06/soap/features/attachment/SOAPMessage</code></p><p> and </p><p><code>http://www.w3.org/2002/06/soap/features/attachment/SecondaryPartBag</code></p><p> properties may
interact with or affect the contents of other properties (from a MEP or
another feature) defining the message sent. It is up to the
implementation to specify how those properties interact.</p><p>For example, the <a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624//#singlereqrespmep">Request-Response Message Exchange Pattern</a> in the
<a href="#W3C.WD-soap-part2">[SOAP Part 2]</a> specification defines a
reqres:OutboundMessage property that represents the current outbound
message in the message exchange. If the Request-Response Message
Exchange Pattern is used in conjunction with this feature, then the
reqres:OutboundMessage property is initialized to represent the
compound SOAP Structure (see diagram below).</p><img src="PropertiesInteraction.png" alt="Properties Interaction Diagram." /><div class="div2">
<h3><a id="sendingCompound" name="sendingCompound" />5.1 Sending a compound SOAP structure</h3><p>To use this feature, a SOAP node sending a message instantiates a
local message exchange context. Property definition for the Attachment FeatureProperty NameProperty Value
SOAPMessage
A representation of the primary SOAP message part of the
outbound message.
SecondaryPartBag
A representation of all the secondary parts of the outbound
message.
describes
how the context is initialized.</p><div id="tabsend"><table border="1"><caption>Property definition for the Attachment Feature</caption><tbody><tr><th>Property Name</th><th>Property Value</th></tr><tr><td>
<code>SOAPMessage</code>
</td><td>A representation of the primary SOAP message part of the
outbound message.
</td></tr><tr><td>
<code>SecondaryPartBag</code>
</td><td>A representation of all the secondary parts of the outbound
message.
</td></tr></tbody></table></div><p>
There may be other properties related to the operation of the
message exchange context instance. Such properties are initialized
according to their own feature specifications.
</p></div><div class="div2">
<h3><a id="receivingCompound" name="receivingCompound" />5.2 Receiving a compound SOAP structure</h3><p>When the SOAP protocol binding instance at the receiving SOAP node
starts to receive an inbound message using this feature, it
(logically) instantiates a message exchange context. Property definition for the Attachment FeatureProperty NameProperty Value
SOAPMessage
A representation of the primary SOAP message part of the
inbound message.
SecondaryPartBag
A representation of all the secondary parts of the inbound
message.
describes the properties that the binding
initializes as part of the context's instantiation.</p><div id="tabrec"><table border="1"><caption>Property definition for the Attachment Feature</caption><tbody><tr><th>Property Name</th><th>Property Value</th></tr><tr><td>
<code>SOAPMessage</code>
</td><td>A representation of the primary SOAP message part of the
inbound message.
</td></tr><tr><td>
<code>SecondaryPartBag</code>
</td><td>A representation of all the secondary parts of the inbound
message.
</td></tr></tbody></table></div><p>
There may be other properties related to the operation of the
message exchange context instance. Such properties are initialized
according to their own feature specifications.
</p></div></div><div class="div1">
<h2><a id="implementation" name="implementation" />6 Implementation</h2><p>The compound SOAP structure model is abstract in the sense that it
does not define an actual means by which compound SOAP structures are
represented or transmitted by a SOAP binding. This section describes
the requirements on any binding that uses this feature to transmit
SOAP compound structures; the definition of any particular
binding, or of particular representations of compound structures to be
used by such bindings, is outside the scope of this specification.</p><p>A binding that supports the transmission of compound SOAP structures
MUST provide the following:</p><ul><li><p>A means by which the primary and secondary parts are made
available to the receiving party. Typically, this is achieved by
transmitting all of the parts from the sender to the receiver,
using binding-specified means. One option for achieving such
transmission is to use an encapsulation mechanism (e.g. DIME or
MIME) to prepare a single data stream containing all of the parts,
and to then transmit the encapsulation.</p></li><li><p>A mechanism by which each part is identified using one (or more)
URI(s) </p><p> (see <a href="#W3C.WD-soap-part1">[SOAP Part 1]</a>
<a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624//#useofuris">Use of URIs in
SOAP</a>) </p><p> . The URI scheme used MAY but need not
be the same for all parts. The URI scheme used for multiple
identifiers of a single part MAY but need not be the same.
</p><p>Note: the ability to identify a single part with multiple URIs is
provided because, in general, the Web architecture allows such
multiple names for a single resource. It is anticipated that most
bindings will name each part with a single URI, and through the use
of base URIs, provide for absolute and/or relative URI references
to that URI.
</p></li></ul><p>The compound SOAP structure model is independent of the
underlying protocol used for transmitting 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 transmitted
within the same unit of the underlying protocol. Note that in some
cases, the underlying protocol may also provide the functionality of
the encapsulation mechanism.</p><p>As an example of possible representations that a binding might
implement, consider 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. Such a compound
structure can be represented in several ways including but not limited
to the following:</p><ol class="enumar"><li><p>The primary SOAP message part and the JPEG image may be
encapsulated in a single DIME message and transmitted using an
underlying protocol such as TCP or HTTP (<a href="#RFC2616">[RFC 2616]</a>)
(see <a href="#I-D.nielsen-dime-soap">[WS-Attachments]</a>).</p></li><li><p>The primary SOAP message part and the JPEG image may be
encapsulated in a single MIME Multipart/Related message (<a href="#RFC2387">[RFC 2387]</a>) and transmitted using an underlying protocol
such as HTTP (<a href="#RFC2616">[RFC 2616]</a>) (see <a href="#SOAP-Attachments">[SOAP with attachments]</a>).
</p></li><li><p>The primary SOAP message part may be exchanged using the HTTP
protocol binding without any further encapsulation</p><p>,</p><p> and the JPEG
image </p><p>retrieved at the application's discretion</p><p> using a separate HTTP GET request.</p></li></ol><p>A binding that supports this feature MUST provide a means by which
receivers can distinguish the primary SOAP part from the secondary
parts. A SOAP receiver that supports this feature MUST process the
primary SOAP message part according to the rules for processing SOAP
messages (see <a href="#W3C.WD-soap-part1">[SOAP Part 1]</a>).</p><p>Compound SOAP structures MAY be nested by having a secondary part of
a compound SOAP structure contain another compound SOAP structure. In
this case, the primary SOAP message part is the primary SOAP message
part of the outermost compound SOAP structure and as for any other
secondary part, the semantics of the primary SOAP message part
provides the processing context for the nested compound SOAP
structure(s).</p><p>While a binding that supports this feature MAY provide mechanisms
for verifying the integrity and enumerating the parts of a compound
SOAP structure, this is not a requirement of this feature.</p></div><div class="div1">
<h2><a id="intermediaries" name="intermediaries" />7 Intermediaries</h2><p>A SOAP message can travel through zero or more SOAP
intermediaries. This section describes the requirements posed on SOAP
intermediaries supporting this specification. </p><p>A SOAP intermediary MUST be able to access any secondary
part. </p><p>A forwarding SOAP intermediary MUST in general forward
every secondary parts contained in the incoming SOAP message, except
when the specification for a processed SOAP header block calls for the
part to be removed or changed. An active SOAP intermediary MAY change
or remove any secondary part even in the absence of such a mandate.
</p><p>A SOAP intermediary MAY insert new secondary parts. </p><p>The integrity of references (i.e. URIs) to secondary parts
MUST be maintained accross SOAP intermediaries. That is, a URI which
resolves to a secondary part in an inbound SOAP message MUST continue
to resolve to that part in the outbound message, unless that part was
removed by the SOAP intermediary.
</p></div><div class="div1">
<h2><a id="i18n" name="i18n" />8 Internationalization Considerations</h2><p>This specification does not introduce internationalization
considerations beyond what is introduced by <a href="#W3C.WD-soap-part1">[SOAP Part 1]</a>, and URIs (<a href="#RFC2396">[RFC 2396]</a>). This
specification refers to the specific considerations described by those
specifications.</p></div><div class="div1">
<h2><a id="security" name="security" />9 Security Considerations</h2><p>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.</p><p>Security considerations for media types in general are discussed in
<a href="#RFC2048">[RFC 2048]</a> and in the context of the
"application/postscript" and the "message/external-body" media type in
<a href="#RFC2046">[RFC 2046]</a>.</p><p>To address concerns about integrity and confidentiality, secondary
parts can be digitally signed and encrypted. Typically, a compound SOAP
structure that contains signed or encrypted secondary parts would
include security information about the secondary parts in a security
header of the primary SOAP message part. This specification does not
provide a means to protect a message by encrypting and/or digitally
signing a body, a header, a secondary part, or any combination of them
(or parts of them). Other specifications (see for example <a href="#WS-Security">[WS-Security]</a>) can provide such means.</p></div><div class="div1">
<h2><a id="iana" name="iana" />10 IANA Considerations</h2><p>This specification does not describe any components that require
registration by IANA.</p></div><div class="div1">
<h2><a id="refs" name="refs" />11 References</h2><div class="div2">
<h3><a id="refs-norm" name="refs-norm" />11.1 Normative References</h3><dl><dt class="label"><a id="RFC2026" name="RFC2026" />RFC 2026</dt><dd>IETF "The Internet Standards Process -- Revision 3", S. Bradner, October 1996. (See http://www.ietf.org/rfc/rfc2026.txt.)</dd><dt class="label"><a id="RFC2045" name="RFC2045" />RFC 2045</dt><dd>IETF "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1996. (See http://www.ietf.org/rfc/rfc2045.txt.)</dd><dt class="label"><a id="RFC2046" name="RFC2046" />RFC 2046</dt><dd>IETF "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed, N. Borenstein, November 1996. (See http://www.ietf.org/rfc/rfc2046.txt.)</dd><dt class="label"><a id="RFC2048" name="RFC2048" />RFC 2048</dt><dd>IETF "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", N. Freed, J. Klensin, J. Postel, March 1997. (See http://www.ietf.org/rfc/rfc2048.txt.)</dd><dt class="label"><a id="RFC2119" name="RFC2119" />RFC 2119</dt><dd>IETF "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)</dd><dt class="label"><a id="RFC2387" name="RFC2387" />RFC 2387</dt><dd>IETF "The MIME Multipart/Related Content-type", E. Levinson, August 1998. (See http://www.ietf.org/rfc/rfc2387.txt.)</dd><dt class="label"><a id="RFC2396" name="RFC2396" />RFC 2396</dt><dd>IETF "Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)</dd><dt class="label"><a id="RFC2616" name="RFC2616" />RFC 2616</dt><dd>IETF "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. Mogul, H.F. Nielsen, L. Masinter, P.Leach, T. Berners-Lee, June 1999. (See http://www.ietf.org/rfc/rfc2616.txt.)</dd><dt class="label"><a id="W3C.REC-xml" name="W3C.REC-xml" />XML 1.0</dt><dd>W3C Recommendation "Extensible Markup Language (XML) 1.0 (2nd ed)", T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006)</dd><dt class="label"><a id="W3C.REC-xml-infoset" name="W3C.REC-xml-infoset" />XML Infoset</dt><dd>W3C Recommendation "XML Information Set", J. Cowan, R. Tobin, October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)</dd><dt class="label"><a id="W3C.WD-soap-part1" name="W3C.WD-soap-part1" />SOAP Part 1</dt><dd>W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, June 2002. (See http://www.w3.org/TR/2002/WD-soap12-part1-20020626/.)</dd><dt class="label"><a id="W3C.WD-soap-part2" name="W3C.WD-soap-part2" />SOAP Part 2</dt><dd>W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. F. Nielsen, June 2002. (See http://www.w3.org/TR/2002/WD-soap12-part2-20020626/.)</dd></dl></div><div class="div2">
<h3><a id="N102CD" name="N102CD" />11.2 Informative References</h3><dl><dt class="label"><a id="SOAP-Attachments" name="SOAP-Attachments" />SOAP with attachments</dt><dd>W3C Note "SOAP Messages with Attachments", J. Barton, S. Thatte, H.F. Nielsen, December 2000. (See http://www.w3.org/TR/SOAP-attachments)</dd><dt class="label"><a id="I-D.nielsen-dime-soap" name="I-D.nielsen-dime-soap" />WS-Attachments</dt><dd>Internet draft "WS-Attachments", H.F. Nielsen, E. Christensen, J. Farrell, June 2002.</dd><dt class="label"><a id="WS-Security" name="WS-Security" />WS-Security</dt><dd>"Web Services Security (WS-Security)", C. Kaler, B. Atkinson, G. Della-Libera, S. Hada, M. Hondo, P. Hallam-Baker, J. Klein, B. LaMacchia, P. Leach, J. Manferdelli, H. Maruyama, A. Nadalin, N. Nagaratman, H. Prafullchandra, J. Shewchuk, D. Simon, April 2002 (See http://www-106.ibm.com/developerworks/webservices/library/ws-secure/.)</dd></dl></div></div></div><div class="back"><div class="div1">
<h2><a id="contributors" name="contributors" />A Contributors</h2><p>E. Christensen, Microsoft</p><p>J. Farrell, IBM</p></div><div class="div1">
<h2><a id="History" name="History" />B History</h2><div class="div2">
<h3><a id="N102F9" name="N102F9" />B.1 5 december 2002</h3><ul><li><p>
Solved 385 by creating section <a href="#conformance"><b>1.2 Conformance</b></a>.
</p></li></ul></div><div class="div2">
<h3><a id="N10303" name="N10303" />B.2 4 november 2002</h3><ul><li><p>
Solved 387 by updating section <a href="#name"><b>2 SOAP Feature Name</b></a>.
</p></li><li><p>
Added direct reference to Request-Response MEP in section <a href="#properties"><b>5 Attachment Feature properties</b></a>
</p></li><li><p>
Solved 391 by incorporating <a href="http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0145.html">proposal</a>.
</p></li><li><p>
Solved 277 by updating section <a href="#properties"><b>5 Attachment Feature properties</b></a>. Properties are now named using URIs instead of QNames. This also solves 386.
</p></li></ul></div><div class="div2">
<h3><a id="N10324" name="N10324" />B.3 31 october 2002</h3><ul><li><p>
Solved 392 by adding section <a href="#intermediaries"><b>7 Intermediaries</b></a>.
</p></li><li><p>
Solved 388 by incorporating <a href="http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0157.html">proposal</a>.
</p></li></ul></div><div class="div2">
<h3><a id="N10339" name="N10339" />B.4 31 July 2002</h3><ul><li><p>
Incorporated Noah's and Asir's modifications.
</p></li><li><p>
Further modified last sentence of first para of <a href="#intro"><b>1 Introduction</b></a>.
</p></li><li><p>
In last paragraph of <a href="#terminology"><b>3 Terminology</b></a> changed 'also'
to 'informally'.
</p></li><li><p>
Changed last sentence of Note in <a href="#implementation"><b>6 Implementation</b></a>
to be reversed.
</p></li><li><p>
Changed att:SOAPMessage value definition in <a href="#receivingCompound"><b>5.2 Receiving a compound SOAP structure</b></a> to be in sync with value definition
in <a href="#sendingCompound"><b>5.1 Sending a compound SOAP structure</b></a>.
</p></li><li><p>
Changed last paragraph of <a href="#security"><b>9 Security Considerations</b></a> by replacing
'attachment' by 'secondary part', and by some rewording.
</p></li><li><p>
Added some text in fifth paragraph of <a href="#intro"><b>1 Introduction</b></a> to
say that this spec can be used directly in SOAP bindings or
indirectly through another specification.
</p></li></ul></div><div class="div2">
<h3><a id="N10367" name="N10367" />B.5 30 July 2002</h3><ul><li><p>
Added 'part' 2 times in the last sentence of first paragraph of
abstract.
</p></li><li><p>
Changed Last paragraph of <a href="#intro"><b>1 Introduction</b></a> as per Noah's
suggestion.
</p></li><li><p>
Changed 'may' to 'can' in <a href="#name"><b>2 SOAP Feature Name</b></a>.
</p></li><li><p>
Changed third paragraph of <a href="#model"><b>4 Compound SOAP Structure Model</b></a> as per Noah's suggestion (added 'semantic').
</p></li><li><p>
Changed fourth paragraph of <a href="#model"><b>4 Compound SOAP Structure Model</b></a> as per Noah's suggestion (added 'envelope').
</p></li><li><p>
Changed <a href="#implementation"><b>6 Implementation</b></a> as per Noah's suggestion.
</p></li></ul></div><div class="div2">
<h3><a id="N1038C" name="N1038C" />B.6 22 July 2002</h3><ul><li><p>
Reformatted spec as a WD.
</p></li><li><p>
Added text in abstract to say that attachment is an informal term for part.
</p></li><li><p>
Removed sentence "a priori with any MEP" from <a href="#properties"><b>5 Attachment Feature properties</b></a>.
</p></li><li><p>
Added warning in <a href="#properties"><b>5 Attachment Feature properties</b></a> about potential properties conflicts. Added a figure.
</p></li><li><p>
Removed note from <a href="#sendingCompound"><b>5.1 Sending a compound SOAP structure</b></a>.
</p></li><li><p>
Removed note from <a href="#sendingCompound"><b>5.1 Sending a compound SOAP structure</b></a>.
</p></li><li><p>
Changed NEED NOT to lowercase in <a href="#implementation"><b>6 Implementation</b></a>.
</p></li><li><p>
Added example mentioning MIME multipart in <a href="#implementation"><b>6 Implementation</b></a>.
</p></li><li><p>
Clarified last sentence of last paragraph in <a href="#security"><b>9 Security Considerations</b></a> to read as an example.
</p></li></ul></div></div></div></body></html>