(WS-ReliableMessaging)

Committee Draft 05, February 1, 2007

4 Document identifier: 5 wsrm-1.1-spec-cd-05

6 Location: 7 http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-05.pdf

8 Editors:

9 Doug Davis, IBM <dug@us.ibm.com> 10 Anish Karmarkar, Oracle <Anish.Karmarkar@oracle.com> 11 Gilbert Pilz, BEA <gpilz@bea.com> 12 Steve Winkler, SAP <steve.winkler@sap.com> 13 Ümit Yalçinalp, SAP <umit.yalcinalp@sap.com>

14 Contributors: 15 See the Acknowledgments (Appendix E).

16 Abstract: 17 This specification (WS-ReliableMessaging) describes a protocol that allows messages to be transferred 18 reliably between nodes implementing this protocol in the presence of software component, system, or 19 network failures. The protocol is described in this specification in a transport-independent manner 20 allowing it to be implemented using different network technologies. To support interoperable Web 21 services, a SOAP binding is defined within this specification.

22 The protocol defined in this specification depends upon other Web services specifications for the 23 identification of service endpoint addresses and policies. How these are identified and retrieved are 24 detailed within those specifications and are out of scope for this document.

25 By using the XML [XML], SOAP [SOAP 1.1], [SOAP 1.2] and WSDL [WSDL 1.1] extensibility model, 26 SOAP-based and WSDL-based specifications are designed to be composed with each other to define a 27 rich Web services environment. As such, WS-ReliableMessaging by itself does not define all the features 28 required for a complete messaging solution. WS-ReliableMessaging is a building block that is used in 29 conjunction with other specifications and application-specific protocols to accommodate a wide variety of 30 requirements and scenarios related to the operation of distributed Web services.

31 Status: 32 This document was last revised or approved by the WS-RX on the above date. The level of approval is 33 also listed above. Check the current location noted above for possible later revisions of this document. 34 This document is updated periodically on no particular schedule. Technical Committee members should 35 send comments on this specification to the Technical Committee's email list. Others should send 36 comments to the Technical Committee by using the "Send A Comment" button on the Technical 37 Committee's web page at http://www.oasis-open.org/committees/ws-rx. For information on whether any 38 patents have been disclosed that may be essential to implementing this specification, and any offers of 39 patent licensing terms, please refer to the Intellectual Property Rights section of the Technical 40 Committee web page (http://www.oasis-open.org/committees/ws-rx/ipr.php. The non-normative errata 41 page for this specification is located at http://www.oasis-open.org/committees/ws-rx.

42 Table of Contents

43 1 Introduction..................................................................................................................................................4 44 1.1 Notational Conventions........................................................................................................................4 45 1.2 Namespace..........................................................................................................................................5 46 1.3 Conformance.......................................................................................................................................5 47 2 Reliable Messaging Model..........................................................................................................................6 48 2.1 Glossary...............................................................................................................................................6 49 2.2 Protocol Preconditions.........................................................................................................................7 50 2.3 Protocol Invariants...............................................................................................................................8 51 2.4 Delivery Assurances............................................................................................................................8 52 2.5 Example Message Exchange..............................................................................................................9 53 3 RM Protocol Elements...............................................................................................................................11 54 3.1 Considerations on the Use of Extensibility Points..............................................................................11 55 3.2 Considerations on the Use of "Piggy-Backing"..................................................................................11 56 3.3 Composition with WS-Addressing.....................................................................................................11 57 3.4 Sequence Creation............................................................................................................................12 58 3.5 Closing A Sequence..........................................................................................................................16 59 3.6 Sequence Termination.......................................................................................................................18 60 3.7 Sequences.........................................................................................................................................20 61 3.8 Request Acknowledgement...............................................................................................................21 62 3.9 Sequence Acknowledgement............................................................................................................22 63 4 Faults.........................................................................................................................................................25 64 4.1 SequenceFault Element.....................................................................................................................26 65 4.2 Sequence Terminated........................................................................................................................27 66 4.3 Unknown Sequence...........................................................................................................................27 67 4.4 Invalid Acknowledgement..................................................................................................................28 68 4.5 Message Number Rollover................................................................................................................28 69 4.6 Create Sequence Refused.................................................................................................................29 70 4.7 Sequence Closed...............................................................................................................................29 71 4.8 WSRM Required................................................................................................................................30 72 5 Security Threats and Countermeasures...................................................................................................31 73 5.1 Threats and Countermeasures..........................................................................................................31 74 5.2 Security Solutions and Technologies.................................................................................................33 75 6 Securing Sequences.................................................................................................................................37 76 6.1 Securing Sequences Using WS-Security..........................................................................................37 77 6.2 Securing Sequences Using SSL/TLS................................................................................................38 78 7 References................................................................................................................................................40

79 7.1 Normative...........................................................................................................................................40

80 7.2 Non-Normative...................................................................................................................................41 81 Appendix A. Schema....................................................................................................................................43 82 Appendix B. WSDL.......................................................................................................................................48 83 Appendix C. Message Examples.................................................................................................................50 84 Appendix C.1 Create Sequence..............................................................................................................50 85 Appendix C.2 Initial Transmission...........................................................................................................50 86 Appendix C.3 First Acknowledgement.....................................................................................................52 87 Appendix C.4 Retransmission.................................................................................................................52 88 Appendix C.5 Termination.......................................................................................................................53 89 Appendix D. State Tables.............................................................................................................................55 90 Appendix E. Acknowledgments....................................................................................................................60 91 Appendix F. Revision History.......................................................................................................................61 92 Appendix G. Notices.....................................................................................................................................67

1 Introduction

94 It is often a requirement for two Web services that wish to communicate to do so reliably in the presence

95 of software component, system, or network failures. The primary goal of this specification is to create a

96 modular mechanism for reliable transfer of messages. It defines a messaging protocol to identify, track,

97 and manage the reliable transfer of messages between a source and a destination. It also defines a

98 SOAP binding that is required for interoperability. Additional bindings can be defined.

99 This mechanism is extensible allowing additional functionality, such as security, to be tightly integrated. 100 This specification integrates with and complements the WS-Security [WS-Security], WS-Policy [WS101 Policy], and other Web services specifications. Combined, these allow for a broad range of reliable, 102 secure messaging options.

103 1.1 Notational Conventions

104 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 105 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described 106 in RFC 2119 [KEYWORDS].

107 This specification uses the following syntax to define normative outlines for messages:

108 • The syntax appears as an XML instance, but values in italics indicate data types instead of values.

109 • Characters are appended to elements and attributes to indicate cardinality:

110 o "?" (0 or 1)

111 o "*" (0 or more)

112 o "+" (1 or more)

113 • The character "|" is used to indicate a choice between alternatives.

114 • The characters "[" and "]" are used to indicate that contained items are to be treated as a group 115 with respect to cardinality or choice.

116 • An ellipsis (i.e. "...") indicates a point of extensibility that allows other child or attribute content 117 specified in this document. Additional children elements and/or attributes MAY be added at the 118 indicated extension points but they MUST NOT contradict the semantics of the parent and/or 119 owner, respectively. If an extension is not recognized it SHOULD be ignored.

120 • XML namespace prefixes (See Section 1.2) are used to indicate the namespace of the element 121 being defined.

122 Elements and Attributes defined by this specification are referred to in the text of this document using 123 XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this 124 syntax:

125 • An element extensibility point is referred to using {any} in place of the element name. This 126 indicates that any element name can be used, from any namespace other than the wsrm: 127 namespace.

128 • An attribute extensibility point is referred to using @{any} in place of the attribute name. This 129 indicates that any attribute name can be used, from any namespace other than the wsrm: 130 namespace.

131 1.2 Namespace

132 The XML namespace [XML-ns] URI that MUST be used by implementations of this specification is: 133 http://docs.oasis-open.org/ws-rx/wsrm/200702 134 Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0]

135 document that describes this namespace.

136 Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix 137 is arbitrary and not semantically significant.

138 Table 1

Prefix	Namespace
S	(Either SOAP 1.1 or 1.2)
S11	http://schemas.xmlsoap.org/soap/envelope/
S12	http://www.w3.org/2003/05/soap-envelope
wsrm	http://docs.oasis-open.org/ws-rx/wsrm/200702
wsa	http://www.w3.org/2005/08/addressing
wsaw	http://www.w3.org/2006/05/addressing/wsdl
wsse	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
xs	http://www.w3.org/2001/XMLSchema

139 The normative schema for WS-ReliableMessaging can be found linked from the namespace document 140 that is located at the namespace URI specified above.

141 All sections explicitly noted as examples are informational and are not to be considered normative.

142 1.3 Conformance

143 An implementation is not conformant with this specification if it fails to satisfy one or more of the MUST or 144 REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace 145 identifier for this specification (listed in Section 1.2) within SOAP Envelopes unless it is conformant with 146 this specification.

147 Normative text within this specification takes precedence over normative outlines, which in turn take 148 precedence over the XML Schema [XML Schema Part 1, Part 2] descriptions.

149

2 Reliable Messaging Model

150 Many errors can interrupt a conversation. Messages can be lost, duplicated or reordered. Further the host 151 systems can experience failures and lose volatile state.

152 The WS-ReliableMessaging specification defines an interoperable protocol that enables a Reliable 153 Messaging (RM) Source to accurately determine the disposition of each message it Transmits as 154 perceived by the RM Destination, so as to allow it to resolve any in-doubt status regarding receipt of the 155 message Transmitted. The protocol also enables an RM Destination to efficiently determine which of 156 those messages it Receives have been previously Received, enabling it to filter out duplicate message 157 transmissions caused by the retransmission, by the RM Source, of an unacknowledged message. It also 158 enables an RM Destination to Deliver the messages it Receives to the Application Destination in the order 159 in which they were sent by an Application Source, in the event that they are Received out of order. Note 160 that this specification places no restriction on the scope of the RM Source or RM Destination entities. For 161 example, either can span multiple WSDL Ports or Endpoints.

162 The protocol enables the implementation of a broad range of reliability features which include ordered 163 Delivery, duplicate elimination, and guaranteed receipt. The protocol can also be implemented with a 164 range of robustness characteristics ranging from in-memory persistence that is scoped to a single process 165 lifetime, to replicated durable storage that is recoverable in all but the most extreme circumstances. It is 166 expected that the Endpoints will implement as many or as few of these reliability characteristics as 167 necessary for the correct operation of the application using the protocol. Regardless of which of the 168 reliability features is enabled, the wire protocol does not change.

169 Figure 1 below illustrates the entities and events in a simple reliable exchange of messages. First, the 170 Application Source Sends a message for reliable transfer. The Reliable Messaging Source accepts the 171 message and Transmits it one or more times. After accepting the message, the RM Destination 172 Acknowledges it. Finally, the RM Destination Delivers the message to the Application Destination. The 173 exact roles the entities play and the complete meaning of the events will be defined throughout this 174 specification.

Initial Sender Ultimate Receiver

175 Figure 1: Reliable Messaging Model

176 2.1 Glossary 177 The following definitions are used throughout this specification: 178 Accept: The act of qualifying a message by the RM Destination such that it becomes eligible for Delivery

179 and acknowledgement.

180 Acknowledgement: The communication from the RM Destination to the RM Source indicating the 181 successful receipt of a message. 182 Acknowledgement Message: A message containing a SequenceAcknowledgement header block. 183 Acknowledgement Messages may or may not contain a SOAP body. 184 Acknowledgement Request: A message containing an AckRequested header. Acknowledgement 185 Requests may or may not contain a SOAP body. 186 Application Destination: The Endpoint to which a message is Delivered. 187 Application Source: The Endpoint that Sends a message. 188 Back-channel: When the underlying transport provides a mechanism to return a transport-protocol 189 specific response, capable of carrying a SOAP message, without initiating a new connection, this 190 specification refers to this mechanism as a back-channel. 191 Deliver: The act of transferring responsibility for a message from the RM Destination to the Application 192 Destination. 193 Endpoint: As defined in the WS-Addressing specification [WS-Addressing]; a Web service Endpoint is a 194 (referenceable) entity, processor, or resource to which Web service messages can be addressed. 195 Endpoint references (EPRs) convey the information needed to address a Web service Endpoint. 196 Receive: The act of reading a message from a network connection and accepting it. 197 RM Destination: The Endpoint that Receives messages Transmitted reliably from an RM Source. 198 RM Protocol Header Block: One of Sequence, SequenceAcknowledgement, or AckRequested. 199 RM Source: The Endpoint that Transmits messages reliably to an RM Destination. 200 Send: The act of transferring a message from the Application Source to the RM Source for reliable 201 transfer. 202 Sequence Lifecycle Message: A message that contains one of: CreateSequence, 203 CreateSequenceResponse, CloseSequence, CloseSequenceResponse, TerminateSequence, 204 TerminateSequenceResponse as the child element of the SOAP body element. 205 Sequence Traffic Message: A message containing a Sequence header block. 206 Transmit: The act of writing a message to a network connection.

207 2.2 Protocol Preconditions 208 The correct operation of the protocol requires that a number of preconditions MUST be established prior 209 to the processing of the initial sequenced message: 210 • For any single message exchange the RM Source MUST have an endpoint reference that uniquely 211 identifies the RM Destination Endpoint. 212 • The RM Source MUST have successfully created a Sequence with the RM Destination. 213 • The RM Source MUST be capable of formulating messages that adhere to the RM Destination's 214 policies. 215 • If a secure exchange of messages is REQUIRED, then the RM Source and RM Destination MUST 216 have a security context.

217 2.3 Protocol Invariants

218 During the lifetime of a Sequence, the following invariants are REQUIRED for correctness:

219 • The RM Source MUST assign each message within a Sequence a message number (defined 220 below) beginning at 1 and increasing by exactly 1 for each subsequent message. These numbers 221 MUST be assigned in the same order in which messages are sent by the Application Source.

222 • Within every Acknowledgement Message it issues, the RM Destination MUST include one or more 223 AcknowledgementRange child elements that contain, in their collective ranges, the message 224 number of every message accepted by the RM Destination. The RM Destination MUST exclude, in 225 the AcknowledgementRange elements, the message numbers of any messages it has not 226 accepted. If no messages have been received the RM Destination MUST return None instead of an 227 AcknowledgementRange(s). The RM Destination MAY transmit a Nack for a specific message 228 or messages instead of an AcknowledgementRange(s).

229 • While the Sequence is not closed or terminated, the RM Source SHOULD retransmit 230 unacknowledged messages.

231 2.4 Delivery Assurances

232 This section defines a number of Delivery Assurance assertions, which can be supported by RM Sources 233 and RM Destinations. These assertions can be specified as policy assertions using the WS-Policy 234 framework [[WS-Policy]]. For details on this see the WSRM Policy specification [WS-RM Policy].

235 AtLeastOnce

236 Each message is to be delivered at least once, or else an error MUST be raised by the RM Source and/or 237 RM Destination. The requirement on an RM Source is that it SHOULD retry transmission of every 238 message sent by the Application Source until it receives an acknowledgement from the RM Destination. 239 The requirement on the RM Destination is that it SHOULD retry the transfer to the Application Destination 240 of any message that it accepts from the RM Source, until that message has been successfully delivered. 241 There is no requirement for the RM Destination to apply duplicate message filtering.

242 AtMostOnce

243 Each message is to be delivered at most once. The RM Source MAY retry transmission of 244 unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is 245 that it MUST filter out duplicate messages, i.e. that it MUST NOT deliver a duplicate of a message that 246 has already been delivered.

247 ExactlyOnce

248 Each message is to be delivered exactly once; if a message cannot be delivered then an error MUST be 249 raised by the RM Source and/or RM Destination. The requirement on an RM Source is that it SHOULD 250 retry transmission of every message sent by the Application Source until it receives an acknowledgement 251 from the RM Destination. The requirement on the RM Destination is that it SHOULD retry the transfer to 252 the Application Destination of any message that it accepts from the RM Source until that message has 253 been successfully delivered, and that it MUST NOT deliver a duplicate of a message that has already 254 been delivered.

255 InOrder

256 Messages from each individual sequence are to be delivered in the same order they have been sent by 257 the Application Source. The requirement on an RM Source is that it MUST ensure that the ordinal position 258 of each message in the sequence (as indicated by a message sequence number) is consistent with the

259 order in which the messages have been sent from the Application Source. The requirement on the RM 260 Destination is that it MUST deliver received messages for each sequence in the order indicated by the 261 message numbering. This DeliveryAssurance can be used in combination with any of the AtLeastOnce, 262 AtMostOnce or ExactlyOnce assertions, and the requirements of those assertions MUST also be met. In 263 particular if the AtLeastOnce or ExactlyOnce assertion applies and the RM Destination detects a gap in 264 the sequence then the RM Destination MUST NOT deliver any subsequent messages from that sequence 265 until the missing messages are received or until the sequence is closed.

266 2.5 Example Message Exchange 267

275 6. The 3^rdmessage is the last in this Sequence and the RM Source includes an AckRequested276 header to ensure that it gets a timely SequenceAcknowledgement for the Sequence.

277 7. The RM Destination acknowledges receipt of message numbers 1 and 3 as a result of receiving the 278 RM Source's AckRequested header.

279 8. The RM Source retransmits the unacknowledged message with MessageNumber 2. This is a new 280 message from the perspective of the underlying transport, but it has the same Sequence Identifier 281 and MessageNumber so the RM Destination can recognize it as a duplicate of the earlier message, 282 in case the original and retransmitted messages are both Received. The RM Source includes an 283 AckRequested header in the retransmitted message so the RM Destination will expedite an 284 acknowledgement.

285 9. The RM Destination Receives the second transmission of the message with MessageNumber 2 286 and acknowledges receipt of message numbers 1, 2, and 3.

287 10.The RM Source Receives this Acknowledgement and sends a TerminateSequence message to the 288 RM Destination indicating that the Sequence is completed. The TerminateSequence message 289 indicates that message number 3 was the last message in the Sequence. The RM Destination then 290 reclaims any resources associated with the Sequence.

291 11.The RM Destination Receives the TerminateSequence message indicating that the RM Source will 292 not be sending any more messages. The RM Destination sends a TerminateSequenceResponse 293 message to the RM Source and reclaims any resources associated with the Sequence.

294 The RM Source will expect to Receive Acknowledgements from the RM Destination during the course of a 295 message exchange at occasions described in Section 3 below. Should an Acknowledgement not be 296 Received in a timely fashion, the RM Source MUST re-transmit the message since either the message or 297 the associated Acknowledgement might have been lost. Since the nature and dynamic characteristics of 298 the underlying transport and potential intermediaries are unknown in the general case, the timing of re299 transmissions cannot be specified. Additionally, over-aggressive re-transmissions have been 300 demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of 301 providing a reliable exchange of messages. Consequently, implementers are encouraged to utilize 302 adaptive mechanisms that dynamically adjust re-transmission time and the back-off intervals that are 303 appropriate to the nature of the transports and intermediaries envisioned. For the case of TCP/IP 304 transports, a mechanism similar to that described as RTTM in RFC 1323 [RTTM] SHOULD be 305 considered.

306 Now that the basic model has been outlined, the details of the elements used in this protocol are now 307 provided in Section 3.

308

3 RM Protocol Elements

309 The following sub-sections define the various RM protocol elements, and prescribe their usage by a 310 conformant implementations.

311 3.1 Considerations on the Use of Extensibility Points

312 The following protocol elements define extensibility points at various places. Implementations MAY add 313 child elements and/or attributes at the indicated extension points but MUST NOT contradict the semantics 314 of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver 315 SHOULD ignore the extension.

316 3.2 Considerations on the Use of "Piggy-Backing"

317 Some RM Protocol Header Blocks may be added to messages that are targeted to the same Endpoint to 318 which those headers are to be sent (a concept often referred to as "piggy-backing"), thus saving the 319 overhead of an additional message exchange. Reference parameters MUST be considered when 320 determining whether two EPRs are targeted to the same Endpoint. The determination of if and when a 321 Header Block will be piggy-backed onto another message is made by the entity (RM Source or RM 322 Destination) that is sending the header. In order to ensure optimal and successful processing of RM 323 Sequences, endpoints that receive RM-related messages SHOULD be prepared to process RM Protocol 324 Header Blocks that are included in any message it receives. See the sections that define each RM 325 Protocol Header Block to know which ones may be considered for piggy-backing.

326 3.3 Composition with WS-Addressing

327 When the RM protocol, defined in this specification, is composed with the WS-Addressing specification, 328 the following rules prescribe the constraints on the value of the wsa:Action header:

329 1. When an Endpoint generates a message that carries an RM protocol element, that is defined in 330 the following sections, in the body of a SOAP envelope that Endpoint MUST include in that 331 envelope a wsa:Action SOAP header block whose value is an IRI that is a concatenation of the 332 WS-RM namespace URI, followed by a "/", followed by the value of the local name of the child 333 element of the SOAP body . For example, for a Sequence creation request message as described 334 in section 3.4 below, the value of the wsa:Action IRI would be:

335 http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence 336 2. When an Endpoint generates an Acknowledgement Message that has no element content in the 337 SOAP body, then the value of the wsa:ActionIRI MUST be:

338 http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement 339 3. When an Endpoint generates an Acknowledgement Request that has no element content in the 340 SOAP body, then the value of the wsa:ActionIRI MUST be:

341 http://docs.oasis-open.org/ws-rx/wsrm/200702/AckRequested 342 4. When an Endpoint generates an RM fault as defined in section 4 below, the value of the 343 wsa:Action IRI MUST be as defined in section 4 below.

344 3.4 Sequence Creation

345 The RM Source MUST request creation of an outbound Sequence by sending a CreateSequence346 element in the body of a message to the RM Destination which in turn responds either with a message

347 containing CreateSequenceResponse or a CreateSequenceRefusedfault. The RM Source MAY 348 include an offer to create an inbound Sequence within the CreateSequence message. This offer is 349 either accepted or rejected by the RM Destination in the CreateSequenceResponsemessage.

350 The SOAP version used for the CreateSequence message SHOULD be used for all subsequent 351 messages in or for that Sequence, sent by either the RM Source or the RM Destination.

352 The following exemplar defines the CreateSequence syntax:

353 <wsrm:CreateSequence ...> 354 <wsrm:AcksTo> wsa:EndpointReferenceType </wsrm:AcksTo> 355 <wsrm:Expires ...> xs:duration </wsrm:Expires> ? 356 <wsrm:Offer ...> 357 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 358 <wsrm:Endpoint> wsa:EndpointReferenceType </wsrm:Endpoint> 359 <wsrm:Expires ...> xs:duration </wsrm:Expires> ? 360 <wsrm:IncompleteSequenceBehavior> 361 wsrm:IncompleteSequenceBehaviorType 362 </wsrm:IncompleteSequenceBehavior> ? 363 ... 364 </wsrm:Offer> ? 365 ... 366 </wsrm:CreateSequence> 367 The following describes the content model of the CreateSequence element.

368 /wsrm:CreateSequence

369 This element requests creation of a new Sequence between the RM Source that sends it, and the RM 370 Destination to which it is sent. The RM Source MUST NOT send this element as a header block. The RM 371 Destination MUST respond either with a CreateSequenceResponse response message or a 372 CreateSequenceRefused fault.

373 /wsrm:CreateSequence/wsrm:AcksTo

374 The RM Source MUST include this element in any CreateSequence message it sends. This element is of 375 type wsa:EndpointReferenceType (as specified by WS-Addressing). It specifies the endpoint 376 reference to which messages containing SequenceAcknowledgement header blocks and faults related 377 to the created Sequence are to be sent, unless otherwise noted in this specification (for example, see 378 Section 3.5).

379 Implementations MUST NOT use an endpoint reference in the AcksTo element that would prevent the 380 sending of Sequence Acknowledgements back to the RM Source. For example, using the WS-Addressing 381 "http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM Destination to ever 382 send Sequence Acknowledgements.

383 /wsrm:CreateSequence/wsrm:Expires

384 This element, if present, of type xs:duration specifies the RM Source's requested duration for the 385 Sequence. The RM Destination MAY either accept the requested duration or assign a lesser value of its 386 choosing. A value of "PT0S" indicates that the Sequence will never expire. Absence of the element 387 indicates an implied value of "PT0S".

388 /wsrm:CreateSequence/wsrm:Expires/@{any}

389 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 390 element.

391 /wsrm:CreateSequence/wsrm:Offer

392 This element, if present, enables an RM Source to offer a corresponding Sequence for the reliable 393 exchange of messages Transmitted from RM Destination to RM Source.

394 /wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier

395 The RM Source MUST set the value of this element to an absolute URI (conformant with RFC3986 [URI]) 396 that uniquely identifies the offered Sequence.

397 /wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier/@{any}

398 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 399 element.

400 /wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint

401 An RM Source MUST include this element, of type wsa:EndpointReferenceType (as specified by 402 WS-Addressing). This element specifies the endpoint reference to which Sequence Lifecycle Messages, 403 Acknowledgement Requests, and fault messages related to the offered Sequence are to be sent.

404 Implementations MUST NOT use an endpoint reference in the Endpoint element that would prevent the 405 sending of Sequence Lifecycle Message, etc. For example, using the WS-Addressing 406 "http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM Destination to ever 407 send Sequence Lifecycle Messages (e.g. TerminateSequence) to the RM Source for the Offered 408 Sequence.

409 The Offer of an Endpoint containing the "http://www.w3.org/2005/08/addressing/anonymous" IRI as its 410 address is problematic due to the inability of a source to connect to this address and retry 411 unacknowledged messages (as described in Section 2.3). Note that this specification does not define any 412 mechanisms for providing this assurance. In the absence of an extension that addresses this issue, an 413 RM Destination MUST NOT accept (via the /wsrm:CreateSequenceResponse/wsrm:Accept414 element described below) an Offer that contains the "http://www.w3.org/2005/08/addressing/anonymous" 415 IRI as its address.

416 /wsrm:CreateSequence/wsrm:Offer/wsrm:Expires

417 This element, if present, of type xs:duration specifies the duration for the offered Sequence. A value of 418 "PT0S" indicates that the offered Sequence will never expire. Absence of the element indicates an implied 419 value of "PT0S".

420 /wsrm:CreateSequence/wsrm:Offer/wsrm:Expires/@{any}

421 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 422 element.

423 /wsrm:CreateSequence/wsrm:Offer/wsrm:IncompleteSequenceBehavior 424 This element, if present, specifies the behavior that the destination will exhibit upon the closure or 425 termination of an incomplete Sequence. For the purposes of defining the values used, the term "discard" 426 refers to behavior equivalent to the Application Destination never processing a particular message.

427 A value of “DiscardEntireSequence” indicates that the entire Sequence MUST be discarded if the 428 Sequence is closed, or terminated, when there are one or more gaps in the final 429 SequenceAcknowledgement.

430 A value of “DiscardFollowingFirstGap” indicates that messages in the Sequence beyond the first gap 431 MUST be discarded when there are one or more gaps in the final SequenceAcknowledgement.

432 The default value of “NoDiscard” indicates that no acknowledged messages in the Sequence will be 433 discarded.

434 /wsrm:CreateSequence/wsrm:Offer/{any}

435 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 436 to be passed.

437 /wsrm:CreateSequence/wsrm:Offer/@{any}

438 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 439 element.

440 /wsrm:CreateSequence/{any}

441 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 442 to be passed.

443 /wsrm:CreateSequence/@{any}

444 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 445 element.

446 A CreateSequenceResponse is sent in the body of a response message by an RM Destination in 447 response to receipt of a CreateSequence request message. It carries the Identifier of the created 448 Sequence and indicates that the RM Source can begin sending messages in the context of the identified 449 Sequence.

450 The following exemplar defines the CreateSequenceResponse syntax:

451 <wsrm:CreateSequenceResponse ...> 452 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 453 <wsrm:Expires ...> xs:duration </wsrm:Expires> ? 454 <wsrm:IncompleteSequenceBehavior> 455 wsrm:IncompleteSequenceBehaviorType 456 </wsrm:IncompleteSequenceBehavior> ? 457 <wsrm:Accept ...> 458 <wsrm:AcksTo> wsa:EndpointReferenceType </wsrm:AcksTo> 459 ... 460 </wsrm:Accept> ? 461 ... 462 </wsrm:CreateSequenceResponse> 463 The following describes the content model of the CreateSequenceResponseelement.

464 /wsrm:CreateSequenceResponse

465 This element is sent in the body of the response message in response to a CreateSequence request 466 message. It indicates that the RM Destination has created a new Sequence at the request of the RM 467 Source. The RM Destination MUST NOT send this element as a header block.

468 /wsrm:CreateSequenceResponse/wsrm:Identifier

469 The RM Destination MUST include this element within any CreateSequenceResponse message it sends. 470 The RM Destination MUST set the value of this element to the absolute URI (conformant with RFC3986) 471 that uniquely identifies the Sequence that has been created by the RM Destination.

472 /wsrm:CreateSequenceResponse/wsrm:Identifier/@{any}

473 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 474 element.

475 /wsrm:CreateSequenceResponse/wsrm:Expires

476 This element, if present, of type xs:duration accepts or refines the RM Source's requested duration for 477 the Sequence. It specifies the amount of time after which any resources associated with the Sequence 478 SHOULD be reclaimed thus causing the Sequence to be silently terminated. At the RM Destination this 479 duration is measured from a point proximate to Sequence creation and at the RM Source this duration is 480 measured from a point approximate to the successful processing of the CreateSequenceResponse. A 481 value of "PT0S" indicates that the Sequence will never expire. Absence of the element indicates an 482 implied value of "PT0S". The RM Destination MUST set the value of this element to be equal to or less 483 than the value requested by the RM Source in the corresponding CreateSequence message.

484 /wsrm:CreateSequenceResponse/wsrm:Expires/@{any}

485 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 486 element.

487 /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior 488 This element, if present, specifies the behavior that the destination will exhibit upon the closure or 489 termination of an incomplete Sequence. For the purposes of defining the values used, the term "discard" 490 refers to behavior equivalent to the Application Destination never processing a particular message.

491 A value of “DiscardEntireSequence” indicates that the entire Sequence MUST be discarded if the 492 Sequence is closed, or terminated, when there are one or more gaps in the final 493 SequenceAcknowledgement.

494 A value of “DiscardFollowingFirstGap” indicates that messages in the Sequence beyond the first gap 495 MUST be discarded when there are one or more gaps in the final SequenceAcknowledgement.

496 The default value of “NoDiscard” indicates that no acknowledged messages in the Sequence will be 497 discarded.

498 /wsrm:CreateSequenceResponse/wsrm:Accept

499 This element, if present, enables an RM Destination to accept the offer of a corresponding Sequence for 500 the reliable exchange of messages Transmitted from RM Destination to RM Source.

501 Note: If a CreateSequenceResponse is returned without a child Acceptin response to a 502 CreateSequence that did contain a child Offer, then the RM Source MAY immediately reclaim any 503 resources associated with the unused offered Sequence.

504 /wsrm:CreateSequenceResponse/wsrm:Accept/wsrm:AcksTo

505 The RM Destination MUST include this element, of type wsa:EndpointReferenceType(as specified 506 by WS-Addressing). It specifies the endpoint reference to which messages containing 507 SequenceAcknowledgement header blocks and faults related to the created Sequence are to be sent, 508 unless otherwise noted in this specification (for example, see Section 3.5).

509 Implementations MUST NOT use an endpoint reference in the AcksTo element that would prevent the 510 sending of Sequence Acknowledgements back to the RM Source. For example, using the WS-Addressing 511 "http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM Destination to ever 512 send Sequence Acknowledgements.

513 /wsrm:CreateSequenceResponse/wsrm:Accept/{any}

514 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 515 to be passed.

516 /wsrm:CreateSequenceResponse/wsrm:Accept/@{any}

517 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 518 element.

519 /wsrm:CreateSequenceResponse/{any}

520 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 521 to be passed.

522 /wsrm:CreateSequenceResponse/@{any}

523 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 524 element.

525 3.5 Closing A Sequence

526 There are times during the use of an RM Sequence that the RM Source or RM Destination will wish to 527 discontinue using a Sequence. Simply terminating the Sequence discards the state managed by the RM 528 Destination, leaving the RM Source unaware of the final ranges of messages that were successfully 529 transferred to the RM Destination. To ensure that the Sequence ends with a known final state either the 530 RM Source or RM Destination MAY choose to close the Sequence before terminating it.

531 If the RM Source wishes to close the Sequence, then it sends a CloseSequence element, in the body of 532 a message, to the RM Destination. This message indicates that the RM Destination MUST NOT accept 533 any new messages for the specified Sequence, other than those already accepted at the time the 534 CloseSequence element is interpreted by the RM Destination. Upon receipt of this message, or 535 subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST 536 include a final SequenceAcknowledgement(within which the RM Destination MUST include the Final 537 element) header block on any messages associated with the Sequence destined to the RM Source, 538 including the CloseSequenceResponse message or on any Sequence fault Transmitted to the RM 539 Source.

540 To allow the RM Destination to determine if it has received all of the messages in a Sequence, the RM 541 Source SHOULD include the LastMsgNumber element in any CloseSequence messages it sends. The 542 RM Destination can use this information, for example, to implement the behavior indicated by / 543 wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior. The value of the 544 LastMsgNumber element MUST be the same in all the CloseSequence messages for the closing 545 Sequence.

546 If the RM Destination decides to close a Sequence of its own volition, it MAY inform the RM Source of this 547 event by sending a CloseSequence element, in the body of a message, to the AcksTo EPR of that 548 Sequence. The RM Destination MUST include a final SequenceAcknowledgement (within which the RM 549 Destination MUST include the Finalelement) header block in this message and any subsequent 550 messages associated with the Sequence destined to the RM Source.

551 While the RM Destination MUST NOT accept any new messages for the specified Sequence it MUST still 552 process Sequence Lifecyle Messages and Acknowledgement Requests. For example, it MUST respond to 553 AckRequested, TerminateSequence as well as CloseSequence messages. Note, subsequent 554 CloseSequence messages have no effect on the state of the Sequence.

555 In the case where the RM Destination wishes to discontinue use of a Sequence it is RECOMMENDED 556 that it close the Sequence. Please see Final and the SequenceClosed fault. Whenever possible the 557 SequenceClosed fault SHOULD be used in place of the SequenceTerminatedfault to allow the RM 558 Source to still Receive Acknowledgements.

559 The following exemplar defines the CloseSequence syntax:

560 <wsrm:CloseSequence ...> 561 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 562 <wsrm:LastMsgNumber> wsrm:MessageNumberType </wsrm:LastMsgNumber> ? 563 ... 564 </wsrm:CloseSequence> 565 The following describes the content model of the CloseSequenceelement.

566 /wsrm:CloseSequence

567 This element MAY be sent by an RM Source to indicate that the RM Destination MUST NOT accept any 568 new messages for this Sequence This element MAY also be sent by an RM Destination to indicate that it 569 will not accept any new messages for this Sequence.

570 /wsrm:CloseSequence/wsrm:Identifier

571 The RM Source or RM Destination MUST include this element in any CloseSequence messages it sends. 572 The RM Source or RM Destination MUST set the value of this element to the absolute URI (conformant 573 with RFC3986) of the closing Sequence.

574 /wsrm:CloseSequence/wsrm:LastMessageNumber

575 The RM Source SHOULD include this element in any CloseSequence message it sends. The 576 LastMsgNumber element specifies the highest assigned message number of all the Sequence Traffic 577 Messages for the closing Sequence.

578 /wsrm:CloseSequence/wsrm:Identifier/@{any}

579 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 580 element.

581 /wsrm:CloseSequence/{any}

582 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 583 to be passed.

584 /wsrm:CloseSequence@{any}

585 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 586 element.

587 A CloseSequenceResponse is sent in the body of a message in response to receipt of a 588 CloseSequence request message. It indicates that the responder has closed the Sequence.

589 The following exemplar defines the CloseSequenceResponse syntax:

590 <wsrm:CloseSequenceResponse ...> 591 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 592 ... 593 </wsrm:CloseSequenceResponse>

594 The following describes the content model of the CloseSequenceResponse element.

595 /wsrm:CloseSequenceResponse

596 This element is sent in the body of a message in response to receipt of a CloseSequence request 597 message. It indicates that the responder has closed the Sequence.

598 /wsrm:CloseSequenceResponse/wsrm:Identifier

599 The responder (RM Source or RM Destination) MUST include this element in any 600 CloseSequenceResponse message it sends. The responder MUST set the value of this element to the 601 absolute URI (conformant with RFC3986) of the closing Sequence.

602 /wsrm:CloseSequenceResponse/wsrm:Identifier/@{any}

603 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 604 element.

605 /wsrm:CloseSequenceResponse/{any}

606 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 607 to be passed.

608 /wsrm:CloseSequenceResponse@{any}

609 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 610 element.

611 3.6 Sequence Termination

612 When the RM Source has completed its use of the Sequence it sends a TerminateSequence element, 613 in the body of a message, to the RM Destination to indicate that the Sequence is complete and that it will 614 not be sending any further messages related to the Sequence. The RM Destination can safely reclaim any 615 resources associated with the Sequence upon receipt of the TerminateSequence message. Under 616 normal usage the RM Source will complete its use of the Sequence when all of the messages in the 617 Sequence have been acknowledged. However, the RM Source is free to Terminate or Close a Sequence 618 at any time regardless of the acknowledgement state of the messages.

619 To allow the RM Destination to determine if it has received all of the messages in a Sequence, the RM 620 Source SHOULD include the LastMsgNumber element in any TerminateSequence messages it sends. 621 The RM Destination can use this information, for example, to implement the behavior indicated by / 622 wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior. The value of the 623 LastMsgNumber element in the TerminateSequence message MUST be equal to the value of the 624 LastMsgNumber element in any CloseSequence message(s) sent by the RM Source for the same 625 Sequence.

626 If the RM Destination decides to terminate a Sequence of its own volition, it MAY inform the RM Source of 627 this event by sending a TerminateSequence element, in the body of a message, to the AcksTo EPR for 628 that Sequence. The RM Destination MUST include a final SequenceAcknowledgement(within which 629 the RM Destination MUST include the Finalelement) header block in this message.

630 The following exemplar defines the TerminateSequence syntax:

631 <wsrm:TerminateSequence ...> 632 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 633 <wsrm:LastMsgNumber> wsrm:MessageNumberType </wsrm:LastMsgNumber> ? 634 ... 635 </wsrm:TerminateSequence> 636 The following describes the content model of the TerminateSequenceelement.

637 /wsrm:TerminateSequence

638 This element MAY be sent by an RM Source to indicate it has completed its use of the Sequence. It 639 indicates that the RM Destination can safely reclaim any resources related to the identified Sequence. The 640 RM Source MUST NOT send this element as a header block. The RM Source MAY retransmit this 641 element. Once this element is sent, other than this element, the RM Source MUST NOT send any 642 additional message to the RM Destination referencing this Sequence.

643 This element MAY also be sent by the RM Destination to indicate that it has unilaterally terminated the 644 Sequence. Upon sending this message the RM Destination MUST NOT accept any additional messages

645 (with the exception of the corresponding TerminateSequenceResponse) for this Sequence. Upon 646 receipt of a TerminateSequencethe RM Source MUST NOT send any additional messages (with the 647 exception of the corresponding TerminateSequenceResponse) for this Sequence.

648 /wsrm:TerminateSequence/wsrm:Identifier

649 The RM Source or RM Destination MUST include this element in any TerminateSequence message it 650 sends. The RM Source or RM Destination MUST set the value of this element to the absolute URI 651 (conformant with RFC3986) of the terminating Sequence.

652 /wsrm:TerminateSequence/wsrm:LastMsgNumber

653 The RM Source SHOULD include this element in any TerminateSequence message it sends. The 654 LastMsgNumber element specifies the highest assigned message number of all the Sequence Traffic 655 Messages for the closing Sequence.

656 /wsrm:TerminateSequence/wsrm:Identifier/@{any}

657 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 658 element.

659 /wsrm:TerminateSequence/{any}

660 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 661 to be passed.

662 /wsrm:TerminateSequence/@{any}

663 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 664 element.

665 A TerminateSequenceResponse is sent in the body of a message in response to receipt of a 666 TerminateSequence request message. It indicates that responder has terminated the Sequence.

667 The following exemplar defines the TerminateSequenceResponse syntax:

668 <wsrm:TerminateSequenceResponse ...> 669 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 670 ... 671 </wsrm:TerminateSequenceResponse> 672 The following describes the content model of the TerminateSequenceelement.

673 /wsrm:TerminateSequenceResponse

674 This element is sent in the body of a message in response to receipt of a TerminateSequence request 675 message. It indicates that the responder has terminated the Sequence. The responder MUST NOT send 676 this element as a header block.

677 /wsrm:TerminateSequenceResponse/wsrm:Identifier

678 The responder (RM Source or RM Destination) MUST include this element in any 679 TerminateSequenceResponse message it sends. The responder MUST set the value of this element 680 to the absolute URI (conformant with RFC3986) of the terminating Sequence.

681 /wsrm:TerminateSequenceResponse/wsrm:Identifier/@{any}

682 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 683 element.

684 /wsrm:TerminateSequenceResponse/{any}

685 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 686 to be passed.

687 /wsrm:TerminateSequenceResponse/@{any}

688 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 689 element.

690 On receipt of a TerminateSequence message the receiver (RM Source or RM Destination) MUST 691 respond with a corresponding TerminateSequenceResponse message or generate a fault 692 UnknownSequenceFault if the Sequence is not known.

693 3.7 Sequences

694 The RM protocol uses a Sequence header block to track and manage the reliable transfer of messages. 695 The RM Source MUST include a Sequence header block in all messages for which reliable transfer is 696 REQUIRED. The RM Source MUST identify Sequences with unique Identifier elements and the RM 697 Source MUST assign each message within a Sequence a MessageNumber element that increments by 1 698 from an initial value of 1. These values are contained within a Sequence header block accompanying 699 each message being transferred in the context of a Sequence.

700 The RM Source MUST NOT include more than one Sequence header block in any message.

701 A following exemplar defines its syntax:

702 <wsrm:Sequence ...> 703 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 704 <wsrm:MessageNumber> wsrm:MessageNumberType </wsrm:MessageNumber> 705 ... 706 </wsrm:Sequence>

707 The following describes the content model of the Sequenceheader block.

708 /wsrm:Sequence 709 This protocol element associates the message in which it is contained with a previously established RM 710 Sequence. It contains the Sequence's unique identifier and the containing message's ordinal position 711 within that Sequence. The RM Destination MUST understand the Sequenceheader block. The RM 712 Source MUST assign a mustUnderstand attribute with a value 1/true (from the namespace 713 corresponding to the version of SOAP to which the SequenceSOAP header block is bound) to the 714 Sequence header block element.

715 /wsrm:Sequence/wsrm:Identifier

716 An RM Source that includes a Sequenceheader block in a SOAP envelope MUST include this element in 717 that header block. The RM Source MUST set the value of this element to the absolute URI (conformant 718 with RFC3986) that uniquely identifies the Sequence.

719 /wsrm:Sequence/wsrm:Identifier/@{any}

720 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 721 element.

722 /wsrm:Sequence/wsrm:MessageNumber

723 The RM Source MUST include this element within any Sequence headers it creates. This element is of 724 type MessageNumberType. It represents the ordinal position of the message within a Sequence. 725 Sequence message numbers start at 1 and monotonically increase by 1 throughout the Sequence. See 726 Section 4.5 for Message Number Rollover fault.

727 /wsrm:Sequence/{any}

728 This is an extensibility mechanism to allow different types of information, based on a schema, to be 729 passed.

730 /wsrm:Sequence/@{any}

731 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 732 element.

733 The following example illustrates a Sequence header block.

734 <wsrm:Sequence>735 <wsrm:Identifier>http://example.com/abc</wsrm:Identifier>736 <wsrm:MessageNumber>10</wsrm:MessageNumber>737 </wsrm:Sequence>

738 3.8 Request Acknowledgement

739 The purpose of the AckRequested header block is to signal to the RM Destination that the RM Source is 740 requesting that a SequenceAcknowledgement be sent.

741 The RM Source MAY request an Acknowledgement Message from the RM Destination at any time by 742 independently transmitting an AckRequested header block (i.e. as a header of a SOAP envelope with an 743 empty body). Alternatively the RM Source MAY include an AckRequested header block in any message 744 targeted to the RM Destination. The RM Destination SHOULD process AckRequestedheader blocks 745 that are included in any message it receives. If a non-mustUnderstand fault occurs when processing an 746 AckRequested header block that was piggy-backed, a fault MUST be generated, but the processing of 747 the original message MUST NOT be affected.

748 An RM Destination that Receives a message that contains an AckRequested header block MUST send 749 a message containing a SequenceAcknowledgement header block to the AcksTo endpoint reference 750 (see Section 3.4) for a known Sequence or else generate an UnknownSequence fault. It is 751 RECOMMENDED that the RM Destination return a AcknowledgementRange or None element instead 752 of a Nack element (see Section 3.9).

753 The following exemplar defines its syntax:

754 <wsrm:AckRequested ...> 755 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 756 ... 757 </wsrm:AckRequested> 758 The following describes the content model of the AckRequestedheader block.

759 /wsrm:AckRequested

760 This element requests an Acknowledgement for the identified Sequence.

761 /wsrm:AckRequested/wsrm:Identifier 762 An RM Source that includes an AckRequested header block in a SOAP envelope MUST include this 763 element in that header block. The RM Source MUST set the value of this element to the absolute URI, 764 (conformant with RFC3986), that uniquely identifies the Sequence to which the request applies.

765 /wsrm:AckRequested/wsrm:Identifier/@{any}

766 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 767 element.

768 /wsrm:AckRequested/{any}

769 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 770 to be passed.

771 /wsrm:AckRequested/@{any}

772 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 773 element.

774 3.9 Sequence Acknowledgement

775 The RM Destination informs the RM Source of successful message receipt using a 776 SequenceAcknowledgement header block. Acknowledgements can be explicitly requested using the 777 AckRequested directive (see Section 3.8).

778 The RM Destination MAY Transmit the SequenceAcknowledgement header block independently (i.e. 779 As a header of a SOAP envelope with an empty body). Alternatively, an RM Destination MAY include a 780 SequenceAcknowledgement header block on any SOAP envelope targeted to the endpoint referenced 781 by the AcksTo EPR. The RM Source SHOULD process SequenceAcknowledgementheader blocks 782 that are included in any message it receives. If a non-mustUnderstand fault occurs when processing a 783 SequenceAcknowledgement header that was piggy-backed, a fault MUST be generated, but the 784 processing of the original message MUST NOT be affected.

785 During creation of a Sequence the RM Source MAY specify the WS-Addressing anonymous IRI as the 786 address of the AcksTo EPR for that Sequence. When the RM Source specifies the WS-Addressing 787 anonymous IRI as the address of the AcksToEPR, the RM Destination MUST Transmit any 788 SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be Transmitted 789 on the protocol binding-specific back-channel. Such a channel is provided by the context of a Received 790 message containing a SOAP envelope that contains a Sequenceheader block and/or an AckRequested 791 header block for that same Sequence identifier. When the RM Destination receives an AckRequested 792 header, and the AckTo EPR for that sequence is the WS-Addressing anonymous IRI, the RM Destination 793 SHOULD respond on the protocol binding-specific back-channel provided by the Received message 794 containing the AckRequested header block.

795 The following exemplar defines its syntax:

796 <wsrm:SequenceAcknowledgement ...> 797 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 798 [ [ [ <wsrm:AcknowledgementRange ... 799 Upper="wsrm:MessageNumberType" 800 Lower="wsrm:MessageNumberType"/> + 801 | <wsrm:None/> ] 802 <wsrm:Final/> ? ] 803 | <wsrm:Nack> wsrm:MessageNumberType </wsrm:Nack> + ] 804 805 ... 806 </wsrm:SequenceAcknowledgement>

807 The following describes the content model of the SequenceAcknowledgementheader block.

808 /wsrm:SequenceAcknowledgement

809 This element contains the Sequence Acknowledgement information.

810 /wsrm:SequenceAcknowledgement/wsrm:Identifier

811 An RM Destination that includes a SequenceAcknowledgement header block in a SOAP envelope 812 MUST include this element in that header block. The RM Destination MUST set the value of this element 813 to the absolute URI (conformant with RFC3986) that uniquely identifies the Sequence. The RM

814 Destination MUST NOT include multiple SequenceAcknowledgement header blocks that share the 815 same value for Identifierwithin the same SOAP envelope.

816 /wsrm:SequenceAcknowledgement/wsrm:Identifier/@{any}

817 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 818 element.

819 /wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange

820 The RM Destination MAY include one or more instances of this element within a 821 SequenceAcknowledgement header block. It contains a range of Sequence message numbers 822 successfully accepted by the RM Destination. The ranges MUST NOT overlap. The RM Destination 823 MUST NOT include this element if a sibling Nack or None element is also present as a child of 824 SequenceAcknowledgement.

825 /wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@Upper

826 The RM Destination MUST set the value of this attribute equal to the message number of the highest 827 contiguous message in a Sequence range accepted by the RM Destination.

828 /wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@Lower

829 The RM Destination MUST set the value of this attribute equal to the message number of the lowest 830 contiguous message in a Sequence range accepted by the RM Destination.

831 /wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@{any}

832 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 833 element.

834 /wsrm:SequenceAcknowledgement/wsrm:None

835 The RM Destination MUST include this element within a SequenceAcknowledgement header block if 836 the RM Destination has not accepted any messages for the specified Sequence. The RM Destination 837 MUST NOT include this element if a sibling AcknowledgementRange or Nack element is also present 838 as a child of the SequenceAcknowledgement.

839 /wsrm:SequenceAcknowledgement/wsrm:Final

840 The RM Destination MAY include this element within a SequenceAcknowledgement header block. This 841 element indicates that the RM Destination is not receiving new messages for the specified Sequence. The 842 RM Source can be assured that the ranges of messages acknowledged by this 843 SequenceAcknowledgement header block will not change in the future. The RM Destination MUST 844 include this element when the Sequence is closed. The RM Destination MUST NOT include this element 845 when sending a Nack; it can only be used when sending AcknowledgementRange elements or a None.

846 /wsrm:SequenceAcknowledgement/wsrm:Nack

847 The RM Destination MAY include this element within a SequenceAcknowledgement header block. If 848 used, the RM Destination MUST set the value of this element to a MessageNumberTyperepresenting 849 the MessageNumber of an unreceived message in a Sequence. The RM Destination MUST NOT include 850 a Nack element if a sibling AcknowledgementRangeor Noneelement is also present as a child of 851 SequenceAcknowledgement. Upon the receipt of a Nack, an RM Source SHOULD retransmit the 852 message identified by the Nack. The RM Destination MUST NOT issue a SequenceAcknowledgement 853 containing a Nack for a message that it has previously acknowledged within an 854 AcknowledgementRange. The RM Source SHOULD ignore a SequenceAcknowledgement containing 855 a Nack for a message that has previously been acknowledged within an AcknowledgementRange.

856 /wsrm:SequenceAcknowledgement/{any}

857 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 858 to be passed.

859 /wsrm:SequenceAcknowledgement/@{any}

860 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 861 element.

862 The following examples illustrate SequenceAcknowledgement elements:

863 • Message numbers 1...10 inclusive in a Sequence have been accepted by the RM Destination.

864 <wsrm:SequenceAcknowledgement>865 <wsrm:Identifier>http://example.com/abc</wsrm:Identifier>866 <wsrm:AcknowledgementRange Upper="10" Lower="1"/>867 </wsrm:SequenceAcknowledgement>

868 • Message numbers 1..2, 4..6, and 8..10 inclusive in a Sequence have been accepted by the RM 869 Destination, messages 3 and 7 have not been accepted.

870 <wsrm:SequenceAcknowledgement>871 <wsrm:Identifier>http://example.com/abc</wsrm:Identifier>872 <wsrm:AcknowledgementRange Upper="2" Lower="1"/>873 <wsrm:AcknowledgementRange Upper="6" Lower="4"/>874 <wsrm:AcknowledgementRange Upper="10" Lower="8"/>875 </wsrm:SequenceAcknowledgement>

876 • Message number 3 in a Sequence has not been accepted by the RM Destination.

877 <wsrm:SequenceAcknowledgement>878 <wsrm:Identifier>http://example.com/abc</wsrm:Identifier>879 <wsrm:Nack>3</wsrm:Nack>880 </wsrm:SequenceAcknowledgement>

881

4 Faults

882 Faults for the CreateSequence message exchange are treated as defined in WS-Addressing. Create 883 Sequence Refused is a possible fault reply for this operation. Unknown Sequence is a fault generated by 884 Endpoints when messages carrying RM header blocks targeted at unrecognized or terminated Sequences 885 are detected. WSRMRequired is a fault generated an RM Destination that requires the use of WS-RM on 886 a Received message that did not use the protocol. All other faults in this section relate to known 887 Sequences. Destinations that generate faults related to known sequences SHOULD transmit those faults. 888 If transmitted, such faults MUST be transmitted to the same [destination] as Acknowledgement 889 messages.

890 Entities that generate WS-ReliableMessaging faults MUST include as the [action] property the default fault 891 action IRI defined below. The value from the W3C Recommendation is below for informational purposes: 892 http://docs.oasis-open.org/ws-rx/wsrm/200702/fault

893 The faults defined in this section are generated if the condition stated in the preamble is met. Fault 894 handling rules are defined in section 6 of WS-Addressing SOAP Binding.

895 The definitions of faults use the following properties:

896 [Code] The fault code.

897 [Subcode] The fault subcode.

898 [Reason] The English language reason element.

899 [Detail] The detail element(s). If absent, no detail element is defined for the fault. If more than one detail 900 element is defined for a fault, implementations MUST include the elements in the order that they are 901 specified.

902 Entities that generate WS-ReliableMessaging faults MUST set the [Code] property to either "Sender" or 903 "Receiver". These properties are serialized into text XML as follows:

SOAP Version	Sender	Receiver
SOAP 1.1	S11:Client	S11:Server
SOAP 1.2	S:Sender	S:Receiver

904 The properties above bind to a SOAP 1.2 fault as follows:

905 <S:Envelope> 906 <S:Header> 907 <wsa:Action> 908 http://docs.oasis-open.org/ws-rx/wsrm/200702/fault 909 </wsa:Action> 910  911 </S:Header> 912 <S:Body> 913 <S:Fault> 914 <S:Code> 915 <S:Value> [Code] </S:Value> 916 <S:Subcode> 917 <S:Value> [Subcode] </S:Value> 918 </S:Subcode> 919 </S:Code> 920 <S:Reason> 921 <S:Text xml:lang="en"> [Reason] </S:Text> 922 </S:Reason> 923 <S:Detail> 924 [Detail]

925 ... 926 </S:Detail>927 </S:Fault>928 </S:Body>929 </S:Envelope>

930 The properties above bind to a SOAP 1.1 fault as follows when the fault is triggered by processing an RM 931 header block:

932 <S11:Envelope> 933 <S11:Header> 934 <wsrm:SequenceFault> 935 <wsrm:FaultCode> wsrm:FaultCodes </wsrm:FaultCode> 936 <wsrm:Detail> [Detail] </wsrm:Detail> 937 ... 938 </wsrm:SequenceFault> 939  940 </S11:Header> 941 <S11:Body> 942 <S11:Fault> 943 <faultcode> [Code] </faultcode> 944 <faultstring> [Reason] </faultstring> 945 </S11:Fault> 946 </S11:Body> 947 </S11:Envelope>

948 The properties bind to a SOAP 1.1 fault as follows when the fault is generated as a result of processing a 949 CreateSequence request message:

950 <S11:Envelope> 951 <S11:Body> 952 <S11:Fault> 953 <faultcode> [Subcode] </faultcode> 954 <faultstring> [Reason] </faultstring> 955 </S11:Fault> 956 </S11:Body> 957 </S11:Envelope>

958 4.1 SequenceFault Element

959 The purpose of the SequenceFault element is to carry the specific details of a fault generated during 960 the reliable messaging specific processing of a message belonging to a Sequence. WS961 ReliableMessaging nodes MUST use the SequenceFault container only in conjunction with the SOAP 962 1.1 fault mechanism. WS-ReliableMessaging nodes MUST NOT use the SequenceFault container in 963 conjunction with the SOAP 1.2 binding.

964 The following exemplar defines its syntax:

965 <wsrm:SequenceFault ...> 966 <wsrm:FaultCode> wsrm:FaultCodes </wsrm:FaultCode> 967 <wsrm:Detail> ... </wsrm:Detail> ? 968 ... 969 </wsrm:SequenceFault>

970 The following describes the content model of the SequenceFaultelement.

971 /wsrm:SequenceFault

972 This is the element containing Sequence information for WS-ReliableMessaging

973 /wsrm:SequenceFault/wsrm:FaultCode

974 WS-ReliableMessaging nodes that generate a SequenceFault MUST set the value of this element to a 975 qualified name from the set of fault [Subcodes] defined below.

976 /wsrm:SequenceFault/wsrm:Detail 977 This element, if present, carries application specific error information related to the fault being described.

978 /wsrm:SequenceFault/wsrm:Detail/{any} 979 The application specific error information related to the fault being described.

980 /wsrm:SequenceFault/wsrm:Detail/@{any} 981 The application specific error information related to the fault being described.

982 /wsrm:SequenceFault/{any} 983 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 984 to be passed.

985 /wsrm:SequenceFault/@{any} 986 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 987 element.

988 4.2 Sequence Terminated

989 The Endpoint that generates this fault SHOULD make every reasonable effort to notify the corresponding 990 Endpoint of this decision.

991 Properties:

992 [Code] Sender or Receiver

993 [Subcode] wsrm:SequenceTerminated

994 [Reason] The Sequence has been terminated due to an unrecoverable error.

995 [Detail] 996 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

Generated by	Condition	Action Upon Generation	Action Upon Receipt
RM Source or RM Destination.	Encountering an unrecoverable condition or detection of violation of the protocol.	Sequence termination.	MUST terminate the Sequence if not otherwise terminated.

997 4.3 Unknown Sequence 998 Properties: 999 [Code] Sender 1000 [Subcode] wsrm:UnknownSequence 1001 [Reason] The value of wsrm:Identifier is not a known Sequence identifier.

1002 [Detail] 1003 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

Generated by	Condition	Action Upon Generation	Action Upon Receipt
RM Source or RM Destination.	In response to a message containing an unknown or terminated Sequence identifier.	None.	MUST terminate the Sequence if not otherwise terminated.

1004 4.4 Invalid Acknowledgement

1005 An example of when this fault is generated is when a message is Received by the RM Source containing 1006 a SequenceAcknowledgementcovering messages that have not been sent. 1007 [Code] Sender 1008 [Subcode] wsrm:InvalidAcknowledgement 1009 [Reason] The SequenceAcknowledgement violates the cumulative Acknowledgement invariant. 1010 [Detail]

1011 <wsrm:SequenceAcknowledgement ...> ... </wsrm:SequenceAcknowledgement>

Generated by	Condition	Action Upon Generation	Action Upon Receipt
RM Source.	In response to aSequenceAcknowledgement that violate the invariants stated in 2.3 or any of the requirements in 3.9 about valid combinations of AckRange, Nack and None in a singleSequenceAcknowledgement element or with respect to already Received such elements.	Unspecified.	Unspecified.

1012 4.5 Message Number Rollover 1013 If the condition listed below is reached, the RM Destination MUST generate this fault. 1014 Properties: 1015 [Code] Sender 1016 [Subcode] wsrm:MessageNumberRollover 1017 [Reason] The maximum value for wsrm:MessageNumber has been exceeded. 1018 [Detail]

1019 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>1020 <wsrm:MaxMessageNumber> wsrm:MessageNumberType </wsrm:MaxMessageNumber>

Generated by	Condition	Action Upon Generation	Action Upon Receipt
RM Destination.	Message number in /wsrm:Sequence/wsrm:MessageNumber of a Received message exceeds the internal limitations of an RM Destination or reaches the maximum value of 9,223,372,036,854,775,8 07.	RM Destination SHOULD continue to accept undelivered messages until the Sequence is closed or terminated.	RM Source SHOULD continue to retransmit undelivered messages until the Sequence is closed or terminated.

1021 4.6 Create Sequence Refused 1022 Properties: 1023 [Code] Sender or Receiver 1024 [Subcode] wsrm:CreateSequenceRefused 1025 [Reason] The Create Sequence request has been refused by the RM Destination. 1026 [Detail]

1027 xs:any

Generated by	Condition	Action Upon Generation	Action Upon Receipt
RM Destination.	In response to a CreateSequencemessage when the RM Destination does not wish to create a new Sequence.	Unspecified.	Sequence terminated.

1028 4.7 Sequence Closed 1029 This fault is generated by an RM Destination to indicate that the specified Sequence has been closed.

1030 This fault MUST be generated when an RM Destination is asked to accept a message for a Sequence that 1031 is closed. 1032 Properties: 1033 [Code] Sender 1034 [Subcode] wsrm:SequenceClosed 1035 [Reason] The Sequence is closed and cannot accept new messages. 1036 [Detail]

1037 <wsrm:Identifier...> xs:anyURI </wsrm:Identifier>

Generated by	Condition	Action Upon Generation	Action Upon Receipt
RM Destination.	In response to a message that belongs to a Sequence that is already closed.	Unspecified.	Sequence closed.

1038 4.8 WSRM Required 1039 If an RM Destination requires the use of WS-RM, this fault is generated when it Receives an incoming 1040 message that did not use this protocol. 1041 Properties: 1042 [Code] Sender 1043 [Subcode] wsrm:WSRMRequired 1044 [Reason] The RM Destination requires the use of WSRM. 1045 [Detail] 1046 xs:any

1047

5 Security Threats and Countermeasures

1048 This specification considers two sets of security requirements, those of the applications that use the WS1049 RM protocol and those of the protocol itself.

1050 This specification makes no assumptions about the security requirements of the applications that use WS1051 RM. However, once those requirements have been satisfied within a given operational context, the 1052 addition of WS-RM to this operational context should not undermine the fulfillment of those requirements; 1053 the use of WS-RM should not create additional attack vectors within an otherwise secure system.

1054 There are many other security concerns that one may need to consider when implementing or using this 1055 protocol. The material below should not be considered as a "check list". Implementers and users of this 1056 protocol are urged to perform a security analysis to determine their particular threat profile and the 1057 appropriate responses to those threats.

1058 Implementers are also advised that there is a core tension between security and reliable messaging that 1059 can be problematic if not addressed by implementations; one aspect of security is to prevent message 1060 replay but one of the invariants of this protocol is to resend messages until they are acknowledged. 1061 Consequently, if the security sub-system processes a message but a failure occurs before the reliable 1062 messaging sub-system Receives that message, then it is possible (and likely) that the security sub-system 1063 will treat subsequent copies as replays and discard them. At the same time, the reliable messaging sub1064 system will likely continue to expect and even solicit the missing message(s). Care should be taken to 1065 avoid and prevent this condition.

1066 5.1 Threats and Countermeasures

1067 The primary security requirement of this protocol is to protect the specified semantics and protocol 1068 invariants against various threats. The following sections describe several threats to the integrity and 1069 operation of this protocol and provide some general outlines of countermeasures to those threats. 1070 Implementers and users of this protocol should keep in mind that all threats are not necessarily applicable 1071 to all operational contexts.

1072 5.1.1 Integrity Threats

1073 In general, any mechanism which allows an attacker to alter the information in a Sequence Traffic 1074 Message, Sequence Lifecycle Message, Acknowledgement Messages, Acknowledgement Request, or 1075 Sequence-related fault, or which allows an attacker to alter the correlation of a RM Protocol Header Block 1076 to its intended message represents a threat to the WS-RM protocol.

1077 For example, if an attacker is able to swap Sequence headers on messages in transit between the RM 1078 Source and RM Destination then they have undermined the implementation's ability to guarantee the first 1079 invariant described in Section 2.3. The result is that there is no way of guaranteeing that messages will be 1080 Delivered to the Application Destination in the same order that they were sent by the Application Source.

1081 5.1.1.1 Countermeasures

1082 Integrity threats are generally countered via the use of digital signatures some level of the communication 1083 protocol stack. Note that, in order to counter header swapping attacks, the signature SHOULD include 1084 both the SOAP body and any relevant SOAP headers (e.g. Sequence header). Because some headers 1085 (AckRequested, SequenceAcknowledgement) are independent of the body of the SOAP message in which 1086 they occur, implementations MUST allow for signatures that cover only these headers.

1087 5.1.2 Resource Consumption Threats

1088 The creation of a Sequence with an RM Destination consumes various resources on the systems used to 1089 implement that RM Destination. These resources can include network connections, database tables, 1090 message queues, etc. This behavior can be exploited to conduct denial of service attacks against an RM 1091 Destination. For example, a simple attack is to repeatedly send CreateSequence messages to an RM 1092 Destination. Another attack is to create a Sequence for a service that is known to require in-order 1093 message Delivery and use this Sequence to send a stream of very large messages to that service, 1094 making sure to omit message number “1” from that stream.

1095 5.1.2.1 Countermeasures

1096 There are a number of countermeasures against the described resource consumption threats. The 1097 technique advocated by this specification is for the RM Destination to restrict the ability to create a 1098 Sequence to a specific set of entities/principals. This reduces the number of potential attackers and, in 1099 some cases, allows the identity of any attackers to be determined.

1100 The ability to restrict Sequence creation depends, in turn, upon the RM Destination's ability identify and 1101 authenticate the RM Source that issued the CreateSequence message.

1102 5.1.3 Sequence Spoofing Threats

1103 Sequence spoofing is a class of threats in which the attacker uses knowledge of the Identifier for a 1104 particular Sequence to forge Sequence Lifecycle or Traffic Messages. For example the attacker creates a 1105 fake TerminateSequence message that references the target Sequence and sends this message to the 1106 appropriate RM Destination. Some sequence spoofing attacks also require up-to-date knowledge of the 1107 current MessageNumber for their target Sequence.

1108 In general any Sequence Lifecycle Message, RM Protocol Header Block, or sequence-correlated SOAP 1109 fault (e.g. InvalidAcknowledgement) can be used by someone with knowledge of the Sequence identifier 1110 to attack the Sequence. These attacks are “two-way” in that an attacker may choose to target the RM 1111 Source by, for example, inserting a fake SequenceAcknowledgement header into a message that it sends 1112 to the AcksTo EPR of an RM Source.

1113 5.1.3.1 Sequence Hijacking

1114 Sequence hijacking is a specific case of a sequence spoofing attack. The attacker attempts to inject 1115 Sequence Traffic Messages into an existing Sequence by inserting fake Sequence headers into those 1116 messages.

1117 Note that “sequence hijacking” should not be equated with “security session hijacking”. Although a 1118 Sequence may be bound to some form of a security session in order to counter the threats described in 1119 this section, applications MUST NOT rely on WS-RM-related information to make determinations about 1120 the identity of the entity that created a message; applications SHOULD rely only upon information that is 1121 established by the security infrastructure to make such determinations. Failure to observe this rule 1122 creates, among other problems, a situation in which the absence of WS-RM may deprive an application of 1123 the ability to authenticate its peers even though the necessary security processing has taken place.

1124 5.1.3.2 Countermeasures

1125 There are a number of countermeasures against sequence spoofing threats. The technique advocated by 1126 this specification is to consider the Sequence to be a shared resource that is jointly owned by the RM 1127 Source that initiated its creation (i.e. that sent the CreateSequence message) and the RM Destination that 1128 serves as its terminus (i.e. that sent the CreateSequenceResponse message). To counter sequence 1129 spoofing attempts the RM Destination SHOULD ensure that every message or fault that it Receives that 1130 refers to a particular Sequence originated from the RM Source that jointly owns the referenced Sequence. 1131 For its part the RM Source SHOULD ensure that every message or fault that it Receives that refers to a 1132 particular Sequence originated from the RM Destination that jointly owns the referenced Sequence.

1133 For the RM Destination to be able to identify its sequence peer it MUST be able to identify and 1134 authenticate the entity that sent the CreateSequence message. Similarly for the RM Source to identify its 1135 sequence peer it MUST be able to identify and authenticate the entity that sent the 1136 CreateSequenceResponse message. For either the RM Destination or the RM Source to determine if a 1137 message was sent by its sequence peer it MUST be able to identify and authenticate the initiator of that 1138 message and, if necessary, correlate this identity with the sequence peer identity established at sequence 1139 creation time.

1140 5.2 Security Solutions and Technologies

1141 The security threats described in the previous sections are neither new nor unique. The solutions that 1142 have been developed to secure other SOAP-based protocols can be used to secure WS-RM as well. This 1143 section maps the facilities provided by common web services security solutions against countermeasures 1144 described in the previous sections.

1145 Before continuing this discussion, however, some examination of the underlying requirements of the 1146 previously described countermeasures is necessary. Specifically it should be noted that the technique 1147 described in Section 5.1.2.1 has two components. Firstly, the RM Destination identifies and authenticates 1148 the issuer of a CreateSequence message. Secondly, the RM Destination performs an authorization check 1149 against this authenticated identity and determines if the RM Source is permitted to create Sequences with 1150 the RM Destination. Since the facilities for performing this authorization check (runtime infrastructure, 1151 policy frameworks, etc.) lie completely within the domain of individual implementations, any discussion of 1152 such facilities is considered to be beyond the scope of this specification.

1153 5.2.1 Transport Layer Security

1154 This section describes how the facilities provided by SSL/TLS [RFC 4346] can be used to implement the 1155 countermeasures described in the previous sections. The use of SSL/TLS is subject to the constraints 1156 defined in Section 4 of the Basic Security Profile 1.0 [BSP 1.0].

1157 The description provided here is general in nature and is not intended to serve as a complete definition on 1158 the use of SSL/TLS to protect WS-RM. In order to interoperate implementations need to agree on the 1159 choice of features as well as the manner in which they will be used. The mechanisms described in the 1160 Web Services Security Policy Language [SecurityPolicy] MAY be used by services to describe the 1161 requirements and constraints of the use of SSL/TLS.

1162 5.2.1.1 Model

1163 The basic model for using SSL/TLS is as follows:

1164 1. The RM Source establishes an SSL/TLS session with the RM Destination.

1165 2. The RM Source uses this SSL/TLS session to send a CreateSequence message to the RM 1166 Destination.

1167 3. The RM Destination establishes an SSL/TLS session with the RM Source and sends an 1168 asynchronous CreateSequenceResponse using this session. Alternately it may respond with a 1169 synchronous CreateSequenceResponse using the session established in (1).

1170 4. For the lifetime of the Sequence the RM Source uses the SSL/TLS session from (1) to Transmit 1171 any and all messages or faults that refer to that Sequence.

1172 5. For the lifetime of the Sequence the RM Destination either uses the SSL/TLS session established 1173 in (3) to Transmit any and all messages or faults that refer to that Sequence or, for synchronous 1174 exchanges, the RM Destination uses the SSL/TLS session established in (1).

1175 5.2.1.2 Countermeasure Implementation

1176 Used in its simplest fashion (without relying upon any authentication mechanisms), SSL/TLS provides the 1177 necessary integrity qualities to counter the threats described in Section 5.1.1. Note, however, that the 1178 nature of SSL/TLS limits the scope of this integrity protection to a single transport level session. If 1179 SSL/TLS is the only mechanism used to provide integrity, any intermediaries between the RM Source and 1180 the RM Destination MUST be trusted to preserve the integrity of the messages that flow through them.

1181 As noted, the technique described in Sections 5.1.2.1 involves the use of authentication. This specification 1182 advocates either of two mechanisms for authenticating entities using SSL/TLS. In both of these methods 1183 the SSL/TLS server (the party accepting the SSL/TLS connection) authenticates itself to the SSL/TLS 1184 client using an X.509 certificate that is exchanged during the SSL/TLS handshake.

1185 • HTTP Basic Authentication: This method of authentication presupposes that a SOAP/HTTP 1186 binding is being used as part of the protocol stack beneath WS-RM. Subsequent to the 1187 establishment of the SSL/TLS session, the sending party authenticates itself to the receiving party 1188 using HTTP Basic Authentication [RFC 2617]. For example, a RM Source might authenticate itself 1189 to a RM Destination (e.g. when transmitting a Sequence Traffic Message) using BasicAuth. 1190 Similarly the RM Destination might authenticate itself to the RM Source (e.g. when sending an 1191 Acknowledgement) using BasicAuth.

1192 • SSL/TLS Client Authentication: In this method of authentication, the party initiating the 1193 connection authenticates itself to the party accepting the connection using an X.509 certificate 1194 that is exchanged during the SSL/TLS handshake.

1195 To implement the countermeasures described in section 5.1.2.1 the RM Source must authenticate itself 1196 using one the above mechanisms. The authenticated identity can then be used to determine if the RM 1197 Source is authorized to create a Sequence with the RM Destination.

1198 This specification advocates implementing the countermeasures described in section 5.1.3.2 by requiring 1199 an RM node's Sequence peer to be equivalent to their SSL/TLS session peer. This allows the 1200 authorization decisions described in section 5.1.3.2 to be based on SSL/TLS session identity rather than 1201 on authentication information. For example, an RM Destination can determine that a Sequence Traffic 1202 Message rightfully belongs to its referenced Sequence if that message arrived over the same SSL/TLS 1203 session that was used to carry the CreateSequence message for that Sequence. Note that requiring a 1204 one-to-one relationship between SSL/TLS session peer and Sequence peer constrains the lifetime of a 1205 SSL/TLS-protected Sequence to be less than or equal to the lifetime of the SSL/TLS session that is used 1206 to protect that Sequence.

1207 This specification does not preclude the use of other methods of using SSL/TLS to implement the 1208 countermeasures (such as associating specific authentication information with a Sequence) although such 1209 methods are not covered by this document.

1210 Issues specific to the life-cycle management of SSL/TLS sessions (such as the resumption of a SSL/TLS 1211 session) are outside the scope of this specification.

1212 5.2.2 SOAP Message Security

1213 The mechanisms described in WS-Security may be used in various ways to implement the 1214 countermeasures described in the previous sections. This specification advocates using the protocol 1215 described by WS-SecureConversation [SecureConversation] (optionally in conjunction with WS-Trust 1216 [Trust]) as a mechanism for protecting Sequences. The use of WS-Security (as an underlying component 1217 of WS-SecureConversation) is subject to the constraints defined in the Basic Security Profile 1.0.

1218 The description provided here is general in nature and is not intended to serve as a complete definition on 1219 the use of WS-SecureConversation/WS-Trust to protect WS-RM. In order to interoperate implementations 1220 need to agree on the choice of features as well as the manner in which they will be used. The 1221 mechanisms described in the Web Services Security Policy Language MAY be used by services to 1222 describe the requirements and constraints of the use of WS-SecureConversation.

1223 5.2.2.1 Model

1224 The basic model for using WS-SecureConversation is as follows:

1225 1. The RM Source and the RM Destination create a WS-SecureConversation security context. This 1226 may involve the participation of third parties such as a security token service. The tokens 1227 exchanged may contain authentication claims (e.g. X.509 certificates or Kerberos service tickets).

1228 2. During the CreateSequence exchange, the RM Source SHOULD explicitly identify the security 1229 context that will be used to protect the Sequence. This is done so that, in cases where the 1230 CreateSequence message is signed by more than one security context, the RM Source can 1231 indicate which security context should be used to protect the newly created Sequence.

1232 3. For the lifetime of the Sequence the RM Source and the RM Destination use the session key(s) 1233 associated with the security context to sign (as defined by WS-Security) at least the body and any 1234 relevant WS-RM-defined headers of any and all messages or faults that refer to that Sequence.

1235 5.2.2.2 Countermeasure Implementation

1236 Without relying upon any authentication information, the per-message signatures provide the necessary 1237 integrity qualities to counter the threats described in Section 5.1.1.

1238 To implement the countermeasures described in section 5.1.2.1 some mutually agreed upon form of 1239 authentication claims must be provided by the RM Source to the RM Destination during the establishment 1240 of the Security Context. These claims can then be used to determine if the RM Source is authorized to 1241 create a Sequence with the RM Destination.

1242 This specification advocates implementing the countermeasures described in section 5.1.3.2 by requiring 1243 an RM node's Sequence peer to be equivalent to their security context session peer. This allows the 1244 authorization decisions described in section 5.1.3.2 to be based on the identity of the message's security 1245 context rather than on any authentication claims that may have been established during security context 1246 initiation. Note that other methods of using WS-SecureConversation to implement the countermeasures 1247 (such as associating specific authentication claims to a Sequence) are possible but not covered by this 1248 document.

1249 As with transport security, the requisite equivalence of a security context peer and with a Sequence peer 1250 limits the lifetime of a Sequence to the lifetime of the protecting security context. Unlike transport security, 1251 the association between a Sequence and its protecting security context cannot always be established 1252 implicitly at Sequence creation time. This is due to the fact that the CreateSequence and 1253 CreateSequenceResponse messages may be signed by more than one security context.

1254 Issues specific to the life-cycle management of WS-SecureConversation security contexts (such as 1255 amending or renewing contexts) are outside the scope of this specification.

1256

6 Securing Sequences

1257 As noted in Section 5, the RM Source and RM Destination should be able to protect their shared 1258 Sequences against the threat of Sequence Spoofing attacks. There are a number of OPTIONAL means of 1259 achieving this objective depending upon the underlying security infrastructure.

1260 6.1 Securing Sequences Using WS-Security

1261 One mechanism for protecting a Sequence is to include a security token using a 1262 wsse:SecurityTokenReference element from WS-Security (see section 9 in WS1263 SecureConversation) in the CreateSequence element. This establishes an association between the 1264 created (and, if present, offered) Sequence(s) and the referenced security token, such that the RM Source 1265 and Destination MUST use the security token as the basis for authorization of all subsequent interactions 1266 related to the Sequence(s). The wsse:SecurityTokenReference explicitly identifies the token as 1267 there may be more than one token on a CreateSequence message or inferred from the communication 1268 context (e.g. transport protection).

1269 It is RECOMMENDED that a message independent referencing mechanism be used to identify the token, 1270 if the token being referenced supports such mechanism.

1271 The following exemplar defines the CreateSequence syntax when extended to include a 1272 wsse:SecurityTokenReference:

1273 <wsrm:CreateSequence ...> 1274 <wsrm:AcksTo> wsa:EndpointReferenceType </wsrm:AcksTo> 1275 <wsrm:Expires ...> xs:duration </wsrm:Expires> ? 1276 <wsrm:Offer ...> 1277 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> 1278 <wsrm:Endpoint> wsa:EndpointReferenceType </wsrm:Endpoint> 1279 <wsrm:Expires ...> xs:duration </wsrm:Expires> ? 1280 <wsrm:IncompleteSequenceBehavior> 1281 wsrm:IncompleteSequenceBehaviorType 1282 </wsrm:IncompleteSequenceBehavior> ? 1283 ... 1284 </wsrm:Offer> ? 1285 ... 1286 <wsse:SecurityTokenReference> 1287 ... 1288 </wsse:SecurityTokenReference> ? 1289 ... 1290 </wsrm:CreateSequence> 1291 The following describes the content model of the additional CreateSequence elements.

1292 /wsrm:CreateSequence/wsse:SecurityTokenReference

1293 This element uses the extensibility mechanism defined for the CreateSequence element (defined in 1294 section 3.4) to communicate an explicit reference to the security token, using a 1295 wsse:SecurityTokenReference as documented in WS-Security, that the RM Source and Destination 1296 MUST use to authorize messages for the created (and, if present, the offered) Sequence(s). All 1297 subsequent messages related to the created (and, if present, the offered) Sequence(s) MUST 1298 demonstrate proof-of-possession of the secret associated with the token (e.g., by using or deriving from a 1299 private or secret key).

1300 When a RM Source transmits a CreateSequence that has been extended to include a 1301 wsse:SecurityTokenReference it SHOULD ensure that the RM Destination both understands and 1302 will conform to the requirements listed above. In order to achieve this, the RM Source SHOULD include 1303 the UsesSequenceSTR element as a SOAP header block within the CreateSequence message. This

1304 element MUST include a soap:mustUnderstand attribute with a value of ‘true’. Thus the RM Source 1305 can be assured that a RM Destination that responds with a CreateSequenceResponseunderstands 1306 and conforms with the requirements listed above. Note that an RM Destination understanding this header 1307 does not mean that it has processed and understood any WS-Security headers, the fault behavior defined 1308 in WS-Security still applies.

1309 The following exemplar defines the UsesSequenceSTR syntax:

1310 <wsrm:UsesSequenceSTR ... /> 1311 The following describes the content model of the UsesSequenceSTRheader block.

1312 /wsrm:UsesSequenceSTR

1313 This element SHOULD be included as a SOAP header block in CreateSequencemessages that use the 1314 extensibility mechanism described above in this section. The soap:mustUnderstand attribute value 1315 MUST be ‘true’. The receiving RM Destination MUST understand and correctly implement the extension 1316 described above or else generate a soap:MustUnderstand fault, thus aborting the requested 1317 Sequence creation.

1318 The following is an example of a CreateSequencemessage using the 1319 wsse:SecurityTokenReference extension and the UsesSequenceSTR header block:

1320 <soap:Envelope ...> 1321 <soap:Header> 1322 ... 1323 <wsrm:UsesSequenceSTR soap:mustUnderstand=’true’/> 1324 ... 1325 </soap:Header> 1326 <soap:Body> 1327 <wsrm:CreateSequence> 1328 <wsrm:AcksTo> 1329 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 1330 </wsrm:AcksTo> 1331 <wsse:SecurityTokenReference> 1332 ... 1333 </wsse:SecurityTokenReference> 1334 </wsrm:CreateSequence> 1335 </soap:Body> 1336 </soap:Envelope>

1337 6.2 Securing Sequences Using SSL/TLS

1338 One mechanism for protecting a Sequence is to bind the Sequence to the underlying SSL/TLS session(s). 1339 The RM Source indicates to the RM Destination that a Sequence is to be bound to the underlying 1340 SSL/TLS session(s) via the UsesSequenceSSLheader block. If the RM Source wishes to bind a 1341 Sequence to the underlying SSL/TLS sessions(s) it MUST include the UsesSequenceSSLelement as a 1342 SOAP header block within the CreateSequence message.

1343 The following exemplar defines the UsesSequenceSSL syntax:

1344 <wsrm:UsesSequenceSSL soap:mustUnderstand=”true” ... /> 1345 The following describes the content model of the UsesSequenceSSLheader block.

1346 /wsrm:UsesSequenceSSL

1347 The RM Source MAY include this element as a SOAP header block of a CreateSequence message to 1348 indicate to the RM Destination that the resulting Sequence is to be bound to the SSL/TLS session that was 1349 used to carry the CreateSequencemessage. If included, the RM Source MUST mark this header with a 1350 soap:mustUnderstand attribute with a value of ‘true’. The receiving RM Destination MUST understand

1351 and correctly implement the functionality described in Section 5.2.1 or else generate a 1352 soap:MustUnderstand fault, thus aborting the requested Sequence creation.

1353 Note that the use inclusion of the above header by the RM Source implies that all Sequence-related 1354 information (Sequence Lifecycle or Acknowledgment messages or Sequence-related faults) flowing from 1355 the RM Destination to the RM Source will be bound to the SSL/TLS session that is used to carry the 1356 CreateSequenceResponse message.

1357 7 References

1358 7.1 Normative 1359 [KEYWORDS] 1360 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, 1361 March 1997 1362 http://www.ietf.org/rfc/rfc2119.txt 1363 [WS-RM Policy] 1364 OASIS WS-RX Technical Committee Draft, "Web Services ReliableMessaging Policy Assertion( WS-RM 1365 Policy)" February 2007 1366 http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-cd-05.pdf 1367 [SOAP 1.1] 1368 W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000. 1369 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 1370 [SOAP 1.2] 1371 W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" June 2003. 1372 http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ 1373 [URI] 1374 T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 3986, 1375 MIT/LCS, U.C. Irvine, Xerox Corporation, January 2005. 1376 http://ietf.org/rfc/rfc3986 1377 [UUID] 1378 P. Leach, M. Mealling, R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace," RFC 4122, 1379 Microsoft, Refactored Networks - LLC, DataPower Technology Inc, July 2005 1380 http://www.ietf.org/rfc/rfc4122.txt 1381 [XML] 1382 W3C Recommendation, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", September 2006. 1383 http://www.w3.org/TR/REC-xml/ 1384 [XML-ns] 1385 W3C Recommendation, "Namespaces in XML," 14 January 1999. 1386 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 1387 [XML-Schema Part1] 1388 W3C Recommendation, "XML Schema Part 1: Structures," October 2004. 1389 http://www.w3.org/TR/xmlschema-1/

1390 [XML-Schema Part2] 1391 W3C Recommendation, "XML Schema Part 2: Datatypes," October 2004. 1392 http://www.w3.org/TR/xmlschema-2/ 1393 [XPATH 1.0] 1394 W3C Recommendation, "XML Path Language (XPath) Version 1.0," 16 November 1999. 1395 http://www.w3.org/TR/xpath 1396 [WSDL 1.1] 1397 W3C Note, "Web Services Description Language (WSDL 1.1)," 15 March 2001. 1398 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 1399 [WS-Addressing] 1400 W3C Recommendation, “Web Services Addressing 1.0 - Core”, May 2006. 1401 http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/ 1402 W3C Recommendation, “Web Services Addressing 1.0 – SOAP Binding”, May 2006. 1403 http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/

1404 7.2 Non-Normative

1405 [BSP 1.0] 1406 WS-I Working Group Draft. "Basic Security Profile Version 1.0," August 2006

1407 http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html 1408 [RDDL 2.0] 1409 Jonathan Borden, Tim Bray, eds. “Resource Directory Description Language (RDDL) 2.0,” January 2004

1410 http://www.openhealth.org/RDDL/20040118/rddl-20040118.html 1411 [RFC 2617] 1412 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Loutonen, L. Stewart, "HTTP 1413 Authentication: Basic and Digest Access Authentication," June 1999.

1414 http://www.ietf.org/rfc/rfc2617.txt 1415 [RFC 4346] 1416 T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1," April 2006.

1417 http://www.ietf.org/rfc/rfc4346.txt 1418 [WS-Policy] 1419 W3C Member Submission, "Web Services Policy Framework (WS-Policy)," April 2006.

1420 http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/ 1421 [WS-PolicyAttachment] 1422 W3C Member Submission, "Web Services Policy Attachment (WS-PolicyAttachment)," April 2006.

1423 http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment1424 20060425/

1425 [WS-Security] 1426 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: 1427 SOAP Message Security 1.0 (WS-Security 2004)", OASIS Standard 200401, March 2004. 1428 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf 1429 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: 1430 SOAP Message Security 1.1 (WS-Security 2004)", OASIS Standard 200602, February 2006. 1431 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf 1432 [RTTM] 1433 V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1434 1992. 1435 http://www.rfc-editor.org/rfc/rfc1323.txt

1436 [SecurityPolicy] 1437 G. Della-Libra, et. al. "Web Services Security Policy Language (WS-SecurityPolicy)", July 2005

1438 http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf 1439 [SecureConversation] 1440 S. Anderson, et al, "Web Services Secure Conversation Language (WS-SecureConversation)," February 1441 2005.

1442 http://schemas.xmlsoap.org/ws/2004/04/sc/ 1443 [Trust] 1444 S. Anderson, et al, "Web Services Trust Language (WS-Trust)," February 2005.

1445 http://schemas.xmlsoap.org/ws/2005/02/trust

1446

Appendix A. Schema

1447 The normative schema that is defined for WS-ReliableMessaging using [XML-Schema Part1] and [XML1448 Schema Part2] is located at:

1449 http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-schema-200702.xsd

1450 The following copy is provided for reference.

1451 <?xml version="1.0" encoding="UTF-8"?> 1452  1487 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 1488 xmlns:wsa="http://www.w3.org/2005/08/addressing" 1489 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1490 targetNamespace="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1491 elementFormDefault="qualified" attributeFormDefault="unqualified"> 1492 <xs:import namespace="http://www.w3.org/2005/08/addressing" 1493 schemaLocation="http://www.w3.org/2006/03/addressing/ws-addr.xsd"/> 1494  1495 <xs:complexType name="SequenceType"> 1496 <xs:sequence> 1497 <xs:element ref="wsrm:Identifier"/> 1498 <xs:element name="MessageNumber" type="wsrm:MessageNumberType"/> 1499 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1500 maxOccurs="unbounded"/> 1501 </xs:sequence> 1502 <xs:anyAttribute namespace="##other" processContents="lax"/>

1503 </xs:complexType>1504 <xs:element name="Sequence" type="wsrm:SequenceType"/>1505 <xs:element name="SequenceAcknowledgement">1506 <xs:complexType>1507 <xs:sequence>1508 <xs:element ref="wsrm:Identifier"/>1509 <xs:choice>1510 <xs:sequence>1511 <xs:choice>1512 <xs:element name="AcknowledgementRange" maxOccurs="unbounded">1513 <xs:complexType>1514 <xs:sequence/>1515 <xs:attribute name="Upper" type="xs:unsignedLong"1516 use="required"/>1517 <xs:attribute name="Lower" type="xs:unsignedLong"1518 use="required"/>1519 <xs:anyAttribute namespace="##other" processContents="lax"/>1520 </xs:complexType>1521 </xs:element>1522 <xs:element name="None">1523 <xs:complexType>1524 <xs:sequence/>1525 </xs:complexType>1526 </xs:element>1527 </xs:choice>1528 <xs:element name="Final" minOccurs="0">1529 <xs:complexType>1530 <xs:sequence/>1531 </xs:complexType>1532 </xs:element>1533 </xs:sequence>1534 <xs:element name="Nack" type="xs:unsignedLong"1535 maxOccurs="unbounded"/>1536 </xs:choice>1537 <xs:any namespace="##other" processContents="lax" minOccurs="0"1538 maxOccurs="unbounded"/>1539 </xs:sequence>1540 <xs:anyAttribute namespace="##other" processContents="lax"/>1541 </xs:complexType>1542 </xs:element>1543 <xs:complexType name="AckRequestedType">1544 <xs:sequence>1545 <xs:element ref="wsrm:Identifier"/>1546 <xs:any namespace="##other" processContents="lax" minOccurs="0"1547 maxOccurs="unbounded"/>1548 </xs:sequence>1549 <xs:anyAttribute namespace="##other" processContents="lax"/>1550 </xs:complexType>1551 <xs:element name="AckRequested" type="wsrm:AckRequestedType"/>1552 <xs:element name="Identifier">1553 <xs:complexType>1554 <xs:annotation>1555 <xs:documentation>1556 This type is for elements whose [children] is an anyURI and can have1557 arbitrary attributes.1558 </xs:documentation>1559 </xs:annotation>1560 <xs:simpleContent>1561 <xs:extension base="xs:anyURI">1562 <xs:anyAttribute namespace="##other" processContents="lax"/>1563 </xs:extension>1564 </xs:simpleContent>1565 </xs:complexType>

1566 </xs:element> 1567 <xs:element name="Address"> 1568 <xs:complexType> 1569 <xs:simpleContent> 1570 <xs:extension base="xs:anyURI"> 1571 <xs:anyAttribute namespace="##other" processContents="lax"/> 1572 </xs:extension> 1573 </xs:simpleContent> 1574 </xs:complexType> 1575 </xs:element> 1576 <xs:simpleType name="MessageNumberType"> 1577 <xs:restriction base="xs:unsignedLong"> 1578 <xs:minInclusive value="1"/> 1579 <xs:maxInclusive value="9223372036854775807"/> 1580 </xs:restriction> 1581 </xs:simpleType> 1582  1583 <xs:simpleType name="FaultCodes"> 1584 <xs:restriction base="xs:QName"> 1585 <xs:enumeration value="wsrm:SequenceTerminated"/> 1586 <xs:enumeration value="wsrm:UnknownSequence"/> 1587 <xs:enumeration value="wsrm:InvalidAcknowledgement"/> 1588 <xs:enumeration value="wsrm:MessageNumberRollover"/> 1589 <xs:enumeration value="wsrm:CreateSequenceRefused"/> 1590 <xs:enumeration value="wsrm:SequenceClosed"/> 1591 <xs:enumeration value="wsrm:WSRMRequired"/> 1592 <xs:enumeration value="wsrm:UnsupportedSelection"/> 1593 </xs:restriction> 1594 </xs:simpleType> 1595 <xs:complexType name="SequenceFaultType"> 1596 <xs:sequence> 1597 <xs:element name="FaultCode" type="wsrm:FaultCodes"/> 1598 <xs:element name="Detail" type="wsrm:DetailType" minOccurs="0"/> 1599 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1600 maxOccurs="unbounded"/> 1601 </xs:sequence> 1602 <xs:anyAttribute namespace="##other" processContents="lax"/> 1603 </xs:complexType> 1604 <xs:complexType name="DetailType"> 1605 <xs:sequence> 1606 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1607 maxOccurs="unbounded"/> 1608 </xs:sequence> 1609 <xs:anyAttribute namespace="##other" processContents="lax"/> 1610 </xs:complexType> 1611 <xs:element name="SequenceFault" type="wsrm:SequenceFaultType"/> 1612 <xs:element name="CreateSequence" type="wsrm:CreateSequenceType"/> 1613 <xs:element name="CreateSequenceResponse" 1614 type="wsrm:CreateSequenceResponseType"/> 1615 <xs:element name="CloseSequence" type="wsrm:CloseSequenceType"/> 1616 <xs:element name="CloseSequenceResponse" 1617 type="wsrm:CloseSequenceResponseType"/> 1618 <xs:element name="TerminateSequence" type="wsrm:TerminateSequenceType"/> 1619 <xs:element name="TerminateSequenceResponse" 1620 type="wsrm:TerminateSequenceResponseType"/> 1621 <xs:complexType name="CreateSequenceType"> 1622 <xs:sequence> 1623 <xs:element ref="wsrm:AcksTo"/> 1624 <xs:element ref="wsrm:Expires" minOccurs="0"/> 1625 <xs:element name="Offer" type="wsrm:OfferType" minOccurs="0"/> 1626 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1627 maxOccurs="unbounded"> 1628 <xs:annotation>

1629 <xs:documentation> 1630 It is the authors intent that this extensibility be used to 1631 transfer a Security Token Reference as defined in WS-Security. 1632 </xs:documentation> 1633 </xs:annotation> 1634 </xs:any> 1635 </xs:sequence> 1636 <xs:anyAttribute namespace="##other" processContents="lax"/> 1637 </xs:complexType> 1638 <xs:complexType name="CreateSequenceResponseType"> 1639 <xs:sequence> 1640 <xs:element ref="wsrm:Identifier"/> 1641 <xs:element ref="wsrm:Expires" minOccurs="0"/> 1642 <xs:element name="IncompleteSequenceBehavior" 1643 type="wsrm:IncompleteSequenceBehaviorType" minOccurs="0"/> 1644 <xs:element name="Accept" type="wsrm:AcceptType" minOccurs="0"/> 1645 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1646 maxOccurs="unbounded"/> 1647 </xs:sequence> 1648 <xs:anyAttribute namespace="##other" processContents="lax"/> 1649 </xs:complexType> 1650 <xs:complexType name="CloseSequenceType"> 1651 <xs:sequence> 1652 <xs:element ref="wsrm:Identifier"/> 1653 <xs:element ref="wsrm:MessageNumberType"/> 1654 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1655 maxOccurs="unbounded"/> 1656 </xs:sequence> 1657 <xs:anyAttribute namespace="##other" processContents="lax"/> 1658 </xs:complexType> 1659 <xs:complexType name="CloseSequenceResponseType"> 1660 <xs:sequence> 1661 <xs:element ref="wsrm:Identifier"/> 1662 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1663 maxOccurs="unbounded"/> 1664 </xs:sequence> 1665 <xs:anyAttribute namespace="##other" processContents="lax"/> 1666 </xs:complexType> 1667 <xs:complexType name="TerminateSequenceType"> 1668 <xs:sequence> 1669 <xs:element ref="wsrm:Identifier"/> 1670 <xs:element ref="wsrm:MessageNumberType" minOccurs="0"/> 1671 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1672 maxOccurs="unbounded"/> 1673 </xs:sequence> 1674 <xs:anyAttribute namespace="##other" processContents="lax"/> 1675 </xs:complexType> 1676 <xs:complexType name="TerminateSequenceResponseType"> 1677 <xs:sequence> 1678 <xs:element ref="wsrm:Identifier"/> 1679 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1680 maxOccurs="unbounded"/> 1681 </xs:sequence> 1682 <xs:anyAttribute namespace="##other" processContents="lax"/> 1683 </xs:complexType> 1684 <xs:element name="AcksTo" type="wsa:EndpointReferenceType"/> 1685 <xs:complexType name="OfferType"> 1686 <xs:sequence> 1687 <xs:element ref="wsrm:Identifier"/> 1688 <xs:element name="Endpoint" type="wsa:EndpointReferenceType"/> 1689 <xs:element ref="wsrm:Expires" minOccurs="0"/> 1690 <xs:element name="IncompleteSequenceBehavior" 1691 type="wsrm:IncompleteSequenceBehaviorType" minOccurs="0"/>

1692 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1693 maxOccurs="unbounded"/> 1694 </xs:sequence> 1695 <xs:anyAttribute namespace="##other" processContents="lax"/> 1696 </xs:complexType> 1697 <xs:complexType name="AcceptType"> 1698 <xs:sequence> 1699 <xs:element ref="wsrm:AcksTo"/> 1700 <xs:any namespace="##other" processContents="lax" minOccurs="0" 1701 maxOccurs="unbounded"/> 1702 </xs:sequence> 1703 <xs:anyAttribute namespace="##other" processContents="lax"/> 1704 </xs:complexType> 1705 <xs:element name="Expires"> 1706 <xs:complexType> 1707 <xs:simpleContent> 1708 <xs:extension base="xs:duration"> 1709 <xs:anyAttribute namespace="##other" processContents="lax"/> 1710 </xs:extension> 1711 </xs:simpleContent> 1712 </xs:complexType> 1713 </xs:element> 1714 <xs:simpleType name="IncompleteSequenceBehaviorType"> 1715 <xs:restriction base="xs:string"> 1716 <xs:enumeration value="DiscardEntireSequence"/> 1717 <xs:enumeration value="DiscardFollowingFirstGap"/> 1718 <xs:enumeration value="NoDiscard"/> 1719 </xs:restriction> 1720 </xs:simpleType> 1721 <xs:element name="UsesSequenceSTR"> 1722 <xs:complexType> 1723 <xs:sequence/> 1724 <xs:anyAttribute namespace="##other" processContents="lax"/> 1725 </xs:complexType> 1726 </xs:element> 1727 <xs:element name="UsesSequenceSSL"> 1728 <xs:complexType> 1729 <xs:sequence/> 1730 <xs:anyAttribute namespace="##other" processContents="lax"/> 1731 </xs:complexType. 1732 </xs:element> 1733 <xs:element name="UnsupportedElement"> 1734 <xs:simpleType> 1735 <xs:restriction base="xs:QName"/> 1736 </xs:simpleType> 1737 </xs:element> 1738 </xs:schema>

Appendix B. WSDL

1740 This WSDL describes the WS-RM protocol from the point of view of an RM Destination. In the case where 1741 an endpoint acts both as an RM Destination and an RM Source, note that additional messages may be 1742 present in exchanges with that endpoint.

1743 Also note that this WSDL is intended to describe the internal structure of the WS-RM protocol, and will not 1744 generally appear in a description of a WS-RM-capable Web service. See WS-RM Policy [WS-RM Policy] 1745 for a higher-level mechanism to indicate that WS-RM is engaged.

1746 The normative WSDL 1.1 definition for WS-ReliableMessaging is located at:

1747 http://docs.oasis-open.org/ws-rx/wsrm/200702/wsdl/wsrm-1.1-wsdl-200702.wsdl

1748 The following non-normative copy is provided for reference.

1749 <?xml version="1.0" encoding="utf-8"?>1750  1785 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"1786 xmlns:xs="http://www.w3.org/2001/XMLSchema"1787 xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:rm="http://docs.oasis1788 open.org/ws-rx/wsrm/200702" xmlns:tns="http://docs.oasis-open.org/ws1789 rx/wsrm/200702/wsdl" targetNamespace="http://docs.oasis-open.org/ws1790 rx/wsrm/200702/wsdl">

1791 <wsdl:types>

1792 <xs:schema> 1793 <xs:import namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1794 schemaLocation="http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-schema1795 200702.xsd"/> 1796 </xs:schema> 1797 </wsdl:types>

1798 <wsdl:message name="CreateSequence"> 1799 <wsdl:part name="create" element="rm:CreateSequence"/> 1800 </wsdl:message> 1801 <wsdl:message name="CreateSequenceResponse"> 1802 <wsdl:part name="createResponse" element="rm:CreateSequenceResponse"/> 1803 </wsdl:message> 1804 <wsdl:message name="CloseSequence"> 1805 <wsdl:part name="close" element="rm:CloseSequence"/> 1806 </wsdl:message> 1807 <wsdl:message name="CloseSequenceResponse"> 1808 <wsdl:part name="closeResponse" element="rm:CloseSequenceResponse"/> 1809 </wsdl:message> 1810 <wsdl:message name="TerminateSequence"> 1811 <wsdl:part name="terminate" element="rm:TerminateSequence"/> 1812 </wsdl:message> 1813 <wsdl:message name="TerminateSequenceResponse"> 1814 <wsdl:part name="terminateResponse" 1815 element="rm:TerminateSequenceResponse"/> 1816 </wsdl:message>

1817 <wsdl:portType name="SequenceAbstractPortType"> 1818 <wsdl:operation name="CreateSequence"> 1819 <wsdl:input message="tns:CreateSequence" wsaw:Action="http://docs.oasis1820 open.org/ws-rx/wsrm/200702/CreateSequence"/> 1821 <wsdl:output message="tns:CreateSequenceResponse" 1822 wsaw:Action="http://docs.oasis-open.org/ws1823 rx/wsrm/200702/CreateSequenceResponse"/> 1824 </wsdl:operation> 1825 <wsdl:operation name="CloseSequence"> 1826 <wsdl:input message="tns:CloseSequence" wsaw:Action="http://docs.oasis1827 open.org/ws-rx/wsrm/200702/CloseSequence"/> 1828 <wsdl:output message="tns:CloseSequenceResponse" 1829 wsaw:Action="http://docs.oasis-open.org/ws1830 rx/wsrm/200702/CloseSequenceResponse"/> 1831 </wsdl:operation> 1832 <wsdl:operation name="TerminateSequence"> 1833 <wsdl:input message="tns:TerminateSequence" 1834 wsaw:Action="http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequence"/> 1835 <wsdl:output message="tns:TerminateSequenceResponse" 1836 wsaw:Action="http://docs.oasis-open.org/ws1837 rx/wsrm/200702/TerminateSequenceResponse"/> 1838 </wsdl:operation> 1839 </wsdl:portType>

1840 </wsdl:definitions>

1841 Appendix C. Message Examples

1842 Appendix C.1 Create Sequence

1843 Create Sequence

1844 <?xml version="1.0" encoding="UTF-8"?> 1845 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1846 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1847 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1848 <S:Header> 1849 <wsa:MessageID> 1850 http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817 1851 </wsa:MessageID> 1852 <wsa:To>http://example.com/serviceB/123</wsa:To> 1853 <wsa:Action>http://docs.oasis-open.org/ws1854 rx/wsrm/200702/CreateSequence</wsa:Action> 1855 <wsa:ReplyTo> 1856 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 1857 </wsa:ReplyTo> 1858 </S:Header> 1859 <S:Body> 1860 <wsrm:CreateSequence> 1861 <wsrm:AcksTo> 1862 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 1863 </wsrm:AcksTo> 1864 </wsrm:CreateSequence> 1865 </S:Body> 1866 </S:Envelope>

1867 Create Sequence Response

1868 <?xml version="1.0" encoding="UTF-8"?> 1869 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1870 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1871 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1872 <S:Header> 1873 <wsa:To>http://Business456.com/serviceA/789</wsa:To> 1874 <wsa:RelatesTo> 1875 http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8a7c2eb546817 1876 </wsa:RelatesTo> 1877 <wsa:Action> 1878 http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequenceResponse 1879 </wsa:Action> 1880 </S:Header> 1881 <S:Body> 1882 <wsrm:CreateSequenceResponse> 1883 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 1884 </wsrm:CreateSequenceResponse> 1885 </S:Body> 1886 </S:Envelope>

1887 Appendix C.2 Initial Transmission

1888 The following example WS-ReliableMessaging headers illustrate the message exchange in the above 1889 figure. The three messages have the following headers; the third message is identified as the last 1890 message in the Sequence:

1891 Message 1

1892 <?xml version="1.0" encoding="UTF-8"?> 1893 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1894 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1895 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1896 <S:Header> 1897 <wsa:MessageID> 1898 http://Business456.com/guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e 1899 </wsa:MessageID> 1900 <wsa:To>http://example.com/serviceB/123</wsa:To> 1901 <wsa:From> 1902 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 1903 </wsa:From> 1904 <wsa:Action>http://example.com/serviceB/123/request</wsa:Action> 1905 <wsrm:Sequence> 1906 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 1907 <wsrm:MessageNumber>1</wsrm:MessageNumber> 1908 </wsrm:Sequence> 1909 </S:Header> 1910 <S:Body> 1911  1912 </S:Body> 1913 </S:Envelope>

1914 Message 2

1915 <?xml version="1.0" encoding="UTF-8"?> 1916 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1917 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1918 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1919 <S:Header> 1920 <wsa:MessageID> 1921 http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38de 1922 </wsa:MessageID> 1923 <wsa:To>http://example.com/serviceB/123</wsa:To> 1924 <wsa:From> 1925 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 1926 </wsa:From> 1927 <wsa:Action>http://example.com/serviceB/123/request</wsa:Action> 1928 <wsrm:Sequence> 1929 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 1930 <wsrm:MessageNumber>2</wsrm:MessageNumber> 1931 </wsrm:Sequence> 1932 </S:Header> 1933 <S:Body> 1934  1935 </S:Body> 1936 </S:Envelope>

1937 Message 3

1938 <?xml version="1.0" encoding="UTF-8"?> 1939 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1940 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1941 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1942 <S:Header> 1943 <wsa:MessageID> 1944 http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546819 1945 </wsa:MessageID> 1946 <wsa:To>http://example.com/serviceB/123</wsa:To> 1947 <wsa:From> 1948 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 1949 </wsa:From> 1950 <wsa:Action>http://example.com/serviceB/123/request</wsa:Action> 1951 <wsrm:Sequence> 1952 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier>

1953 <wsrm:MessageNumber>3</wsrm:MessageNumber> 1954 </wsrm:Sequence> 1955 <wsrm:AckRequested> 1956 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 1957 </wsrm:AckRequested> 1958 </S:Header> 1959 <S:Body> 1960  1961 </S:Body> 1962 </S:Envelope>

1963 Appendix C.3 First Acknowledgement

1964 Message number 2 has not been accepted by the RM Destination due to some transmission error so it 1965 responds with an Acknowledgement for messages 1 and 3:

1966 <?xml version="1.0" encoding="UTF-8"?> 1967 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1968 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1969 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1970 <S:Header> 1971 <wsa:MessageID> 1972 http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546810 1973 </wsa:MessageID> 1974 <wsa:To>http://Business456.com/serviceA/789</wsa:To> 1975 <wsa:From> 1976 <wsa:Address>http://example.com/serviceB/123</wsa:Address> 1977 </wsa:From> 1978 <wsa:Action> 1979 http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement 1980 </wsa:Action> 1981 <wsrm:SequenceAcknowledgement> 1982 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 1983 <wsrm:AcknowledgementRange Upper="1" Lower="1"/> 1984 <wsrm:AcknowledgementRange Upper="3" Lower="3"/> 1985 </wsrm:SequenceAcknowledgement> 1986 </S:Header> 1987 <S:Body/> 1988 </S:Envelope>

1989 Appendix C.4 Retransmission

1990 The RM Sourcediscovers that message number 2 was not accepted so it resends the message and 1991 requests an Acknowledgement:

1992 <?xml version="1.0" encoding="UTF-8"?> 1993 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 1994 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 1995 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 1996 <S:Header> 1997 <wsa:MessageID> 1998 http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38de 1999 </wsa:MessageID> 2000 <wsa:To>http://example.com/serviceB/123</wsa:To> 2001 <wsa:From> 2002 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 2003 </wsa:From> 2004 <wsa:Action>http://example.com/serviceB/123/request</wsa:Action> 2005 <wsrm:Sequence> 2006 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 2007 <wsrm:MessageNumber>2</wsrm:MessageNumber> 2008 </wsrm:Sequence>

2009 <wsrm:AckRequested> 2010 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 2011 </wsrm:AckRequested> 2012 </S:Header> 2013 <S:Body> 2014  2015 </S:Body> 2016 </S:Envelope>

2017 Appendix C.5 Termination

2018 The RM Destination now responds with an Acknowledgement for the complete Sequence which can then 2019 be terminated:

2020 <?xml version="1.0" encoding="UTF-8"?> 2021 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 2022 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 2023 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 2024 <S:Header> 2025 <wsa:MessageID> 2026 http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546811 2027 </wsa:MessageID> 2028 <wsa:To>http://Business456.com/serviceA/789</wsa:To> 2029 <wsa:From> 2030 <wsa:Address>http://example.com/serviceB/123</wsa:Address> 2031 </wsa:From> 2032 <wsa:Action> 2033 http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement 2034 </wsa:Action> 2035 <wsrm:SequenceAcknowledgement> 2036 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 2037 <wsrm:AcknowledgementRange Upper="3" Lower="1"/> 2038 </wsrm:SequenceAcknowledgement> 2039 </S:Header> 2040 <S:Body/> 2041 </S:Envelope>

2042 Terminate Sequence

2043 <?xml version="1.0" encoding="UTF-8"?> 2044 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 2045 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 2046 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 2047 <S:Header> 2048 <wsa:MessageID> 2049 http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546812 2050 </wsa:MessageID> 2051 <wsa:To>http://example.com/serviceB/123</wsa:To> 2052 <wsa:Action> 2053 http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequence 2054 </wsa:Action> 2055 <wsa:From> 2056 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 2057 </wsa:From> 2058 </S:Header> 2059 <S:Body> 2060 <wsrm:TerminateSequence> 2061 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 2062 <wsrm:LastMsgNumber> 3 </wsrm:LastMsgNumber> 2063 </wsrm:TerminateSequence> 2064 </S:Body> 2065 </S:Envelope> 2066 Terminate Sequence Response

2067 <?xml version="1.0" encoding="UTF-8"?> 2068 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 2069 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 2070 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 2071 <S:Header> 2072 <wsa:MessageID> 2073 http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546813 2074 </wsa:MessageID> 2075 <wsa:To>http://example.com/serviceA/789</wsa:To> 2076 <wsa:Action> 2077 http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequenceResponse 2078 </wsa:Action> 2079 <wsa:RelatesTo> 2080 http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546812 2081 </wsa:RelatesTo> 2082 <wsa:From> 2083 <wsa:Address>http://Business456.com/serviceA/789</wsa:Address> 2084 </wsa:From> 2085 </S:Header> 2086 <S:Body> 2087 <wsrm:TerminateSequenceResponse> 2088 <wsrm:Identifier>http://Business456.com/RM/ABC</wsrm:Identifier> 2089 </wsrm:TerminateSequenceResponse> 2090 </S:Body> 2091 </S:Envelope>

2092

Appendix D. State Tables

2093 This appendix specifies the non-normative state transition tables for RM Source and RM Destination. 2094 The state tables describe the lifetime of a sequence in both the RM Source and the RM Destination 2095 Legend: 2096 The first column of these tables contains the motivating event and has the following format:

Event

Event name [source] {ref}

2097 Where: 2098 ● Event Name: indicates the name of the event. Event Names surrounded by “<>” are optional as 2099 described by the specification. 2100 ● [source]: indicates the source of the event; one of: 2101 ● [msg] a Received message 2102 ● [int]: an internal event such as the firing of a timer 2103 ● [app]: the application 2104 ● [unspec]: the source is unspecified 2105 Each event / state combination cell in the tables in this appendix has the following format:

State Name

Action to take [next state] {ref}

2106 Where:

2107 ● action to take: indicates that the state machine performs the following action. Actions surrounded 2108 by “<>” are optional as described by the specification. “Xmit” is used as a short form for the word 2109 “Transmit”

2110 ● [next state]: indicates the state to which the state machine will advance upon the performance of 2111 the action. For ease of reading the next state “same” indicates that the state does not change.

2112 ● {ref} is a reference to the document section describing the behavior in this cell

2113 “N/A” in a cell indicates a state / event combination self-inconsistent with the state machine; should these 2114 conditions occur, it would indicate an implementation error. A blank cell indicates that the behavior is not 2115 described in this specification and does not indicate normal protocol operation. Implementations MAY 2116 generate a Sequence Terminated fault (see section 4.2) in these circumstances. Robust implementations 2117 MUST be able to operate in a stable manner despite the occurrence of unspecified event / state 2118 combinations.

2119 Table 1 RM Source Sequence State Transition Table 2120 Table 2 RM Destination Sequence State Transition Table

Events			Sequence States
Events	None	Creating	Created	Closing	Closed	Terminating
Create Sequence [unspec] {3.4}	Xmit Create Sequence [Creating] {3.4}	N/A	N/A	N/A	N/A	N/A
Create Sequence Response [msg] {3.4)		Process Create Sequence Response [Created] {3.4}
Create Sequence Refused Fault [msg] {3.4}		No action [None] {4.6}
Send message [app] {2.1}	N/A	N/A	Xmit message [Same] {2}	No action [Same] {2}	N/A	N/A
Retransmit of unack’d message [int]	N/A	N/A	Xmit message [Same] {2.3}	Xmit message [Same] {2.3}	N/A	N/A
SeqAck (non-final)[msg] {3.9}	Generate Unknown Sequence Fault [Same] {4.3}	Generate Unknown Sequence Fault [Same] {4.3}	Process Ack ranges [Same] {3.9}	Process Ack ranges [Same] {3.9}	Process Ack ranges [Same] {3.9}	Process Ack ranges [Same] {3.9}
Nack [msg] {3.9)	Generate Unknown Sequence Fault [Same] {4.3}	Generate Unknown Sequence Fault [Same] {4.3}	<Xmit message (s)> [Same] {3.9}	<Xmit message (s)> [Same] {3.9}	No action [Same]	No action [Same]
Message Number Rollover Fault [msg]	Generate Unknown Sequence Fault [Same] {4.3}	Generate Unknown Sequence Fault [Same] {4.3}	No action [Rollover]	No action [Same]	No action [Same]	No action [Same]
CloseSequence [msg] {3.5}	Generate Unknown Sequence Fault [Same] {4.3}	Generate Unknown Sequence Fault [Same] {4.3}	Xmit CloseSequence Response [Closed] {3.5}	Xmit CloseSequence Response [Closed] {3.5}	Xmit CloseSequence Response [Closed] {3.5}	Generate Unknown Sequence Fault [Same] {4.3}
<Close Sequence>[int] {3.5}	N/A		Xmit Close Sequence [Closing] {3.5}	N/A	N/A	N/A
Close Sequence Response [msg] {3.5}	Generate Unknown Sequence Fault [Same] {4.3}	Generate Unknown Sequence Fault [Same] {4.3}		No action [Closed] {3.5}	No action [Same] {3.5}	No action [Same] {3.5}

Events	Sequence States
Events	None	Creating	Created	Closing	Closed	Terminating
SeqAck (final)	Generate	Generate	Process Ack	Process Ack	Process Ack	Process Ack
[msg]	Unknown	Unknown	ranges	ranges	ranges	ranges
{3.9}	Sequence Fault	Sequence Fault	[Closed] {3.9}	[Closed] {3.9}	[Same]	[Same]
	[Same]	[Same]
	{4.3}	{4.3}
Sequence Closed	Generate	Generate	No action	No action	No action	No action
Fault	Unknown	Unknown	[Closed]	[Closed]	[Same]	[Same]
[msg]	Sequence	Sequence	{4.7}	{4.7}
{4.7}	Fault	Fault
	[Same]	[Same]
	{4.3}	{4.3}
Unknown Sequence			Terminate	Terminate	Terminate	Terminate
Fault			Sequence	Sequence	Sequence	Sequence
[msg]			[None]	[None]	[None]	[None]
{4.3}			{4.3}	{4.3}	{4.3}	{4.3}
Sequence	N/A		Terminate	Terminate	Terminate	Terminate
Terminated Fault			Sequence	Sequence	Sequence	Sequence
[msg]			[None]	[None]	[None]	[None]
{4.2}			{4.2}	{4.2}	{4.2}	{4.2}
TerminateSequence	Generate	Generate	Xmit Terminate	Xmit Terminate	Xmit Terminate	Generate
[msg] {3.6}	Unknown Sequence Fault	Unknown Sequence Fault	Sequence Response [None]	Sequence Response [None]	Sequence Response [None]	Unknown Sequence Fault [Same]
	[Same]	[Same]	{3.6}	{3.6}	{3.6}	{4.3}
	{4.3}	{4.3}
Terminate	N/A	No action	Xmit Terminate	Xmit Terminate	Xmit Terminate	N/A
Sequence		[None]	Sequence	Sequence	Sequence
[int]		{unspec}	[Terminating]	[Terminating]	[Terminating]
Terminate	Generate	Generate				Terminate
Sequence	Unknown	Unknown				Sequence
Response	Sequence	Sequence				[None]
[msg]	Fault	Fault				{3.6}
	[Same]	[Same]
	{4.3}	{4.3}
Expires exceeded	N/A	Terminate	Terminate	Terminate	Terminate	Terminate
[int]		Sequence	Sequence	Sequence	Sequence	Sequence
		[None]	[None]	[None]	[None]	[None]
		{3.7}	{3.7}	{3.7}	{3.7}	{3.7}
Invalid	Generate	Generate	Generate Invalid	Generate Invalid	Generate Invalid	Generate Invalid
Acknowledgement	Unknown	Unknown	Acknowledgemen	Acknowledgemen	Acknowledgemen	Acknowledgemen
[msg]	Sequence	Sequence	t Fault	t Fault	t Fault	t Fault
{4.4]	Fault	Fault	[Same]	[Same]	[Same]	[Same]
	[Same]	[Same]	{4.4}	{4.4}	{4.4}	{4.4}
	{4.3}	{4.3}

Events			Sequence States
Events	None		Created	Closed	Terminating
CreateSequence (successful) [msg/int] {3.4}	Xmit Create Sequence Response [Created] {3.4}	N/A		N/A

Events		Sequence States
Events	None	Created	Closed	Terminating
CreateSequence (unsuccessful) [msg/int] {3.4}	Generate Create Sequence Refused Fault [None] {3.4}	N/A	N/A
Message (with message number within range) [msg]	Generate Unknown Sequence Fault [Same] {4.3}	Accept Message; <Xmit SeqAck> [Same]	Generate Sequence Closed Fault (with SeqAck+Final) [Same] {3.5}	Generate Sequence Terminated Fault [Same] {4.2}
Message (with message number outside of range) [msg]	Generate Unknown Sequence Fault [Same] {4.3}	Xmit Message Number Rollover Fault [Same] {3.7}{4.5}	Generate Sequence Closed Fault (with SeqAck+Final) [Same] {3.5}	Generate Sequence Terminated Fault [Same] {4.2}
<AckRequested> [msg] {3.8}	Generate Unknown Seq Fault [Same] {4.3}	Xmit SeqAck [Same] {3.8}	Xmit SeqAck+Final [Same] {3.9}	Generate Sequence Terminated Fault [Same] {4.2}
CloseSequence [msg] {3.5}	Generate Unknown Sequence Fault [Same] {4.3}	Xmit CloseSequence Response with SeqAck+Final [Closed] {3.5}	Xmit CloseSequence Response with SeqAck+Final [Closed] {3.5}	Generate Sequence Terminated Fault [Same] {4.2}
<CloseSequence autonomously> [int]		Xmit CloseSequence with SeqAck+Final [Closed] {3.5}	Xmit CloseSequence with SeqAck+Final [Same] {3.5}
CloseSequenceResponse [msg] {3.5}	Generate Unknown Sequence Fault [Same] {4.3}		No Action [Closed] {3.5}	Generate Sequence Terminated Fault [Same] {4.2}
TerminateSequence [msg] {3.6)	Generate Unknown Sequence Fault [Same] {4.3}	Xmit Terminate Sequence Response [None] {3.6}	Xmit Terminate Sequence Response [None] {3.6}	Xmit Terminate Sequence Response [None] {3.6}
<TerminateSequence autonomously> [int]		Xmit TerminateSequence with SeqAck+Final [Terminating] {3.6}	Xmit TerminateSequence with SeqAck+Final [Terminating] {3.6}	Xmit TerminateSequence with SeqAck+Final [Terminating] {3.6}
TerminateSequenceResponse [msg]	Generate Unknown Sequence Fault [Same] {4.3}			Terminate Sequence [None]
UnknownSequence Fault [msg] {4.3}		Terminate Sequence [None] {4.3}	Terminate Sequence [None] {4.3}	Terminate Sequence [None] {4.3}
SequenceTerminated Fault [msg] {4.2}		Terminate Sequence [None] {4.2}	Terminate Sequence [None] {4.2}	Terminate Sequence [None] {4.3}
Invalid Acknowledgement Fault [msg] {4.4}	N/A

Events		Sequence States
Events	None	Created	Closed	Terminating
Expires exceeded[int]	N/A	Terminate Sequence [None] {3.4}	Terminate Sequence [None] {3.4}
<Seq Acknowledgement autonomously> [int] {3.9}	N/A	Xmit SeqAck [Same] {3.9}	Xmit SeqAck+Final [Same] {3.9}
Non WSRM message when WSRM required [msg] {4.8}	Generate WSRMRequired Fault [Same] {4.8}	Generate WSRMRequired Fault [Same] {4.8}	Generate WSRMRequired Fault [Same] {4.8}

Appendix E. Acknowledgments

2122 This document is based on initial contribution to OASIS WS-RX Technical Committee by the following 2123 authors:

2124 Ruslan Bilorusets(BEA), Don Box(Microsoft), Luis Felipe Cabrera(Microsoft), Doug Davis(IBM), 2125 Donald Ferguson(IBM), Christopher Ferris-Editor(BM), Tom Freund(IBM), Mary Ann Hondo(IBM), 2126 John Ibbotson(IBM), Lei Jin(BEA), Chris Kaler(Microsoft), David Langworthy-Editor(Microsoft), 2127 Amelia Lewis(TIBCO Software), Rodney Limprecht(Microsoft), Steve Lucco(Microsoft), Don 2128 Mullen(TIBCO Software), Anthony Nadalin(IBM), Mark Nottingham(BEA), David Orchard(BEA), 2129 Jamie Roots(IBM), Shivajee Samdarshi(TIBCO Software), John Shewchuk(Microsoft), Tony 2130 Storey(IBM).

2131 The following individuals have provided invaluable input into the initial contribution:

2132 Keith Ballinger(Microsoft), Stefan Batres(Microsoft), Rebecca Bergersen(Iona), Allen Brown 2133 (Microsoft), Michael Conner(IBM), George Copeland(Microsoft), Francisco Curbera(IBM), Paul 2134 Fremantle(IBM), Steve Graham(IBM), Pat Helland(Microsoft), Rick Hill(Microsoft), Scott 2135 Hinkelman(IBM), Tim Holloway(IBM), Efim Hudis(Microsoft), David Ingham(Microsoft), Gopal 2136 Kakivaya(Microsoft), Johannes Klein(Microsoft), Frank Leymann(IBM), Martin Nally(IBM), Peter 2137 Niblett(IBM), Jeffrey Schlimmer(Microsoft), James Snell(IBM), Keith Stobie(Microsoft), Satish 2138 Thatte(Microsoft), Stephen Todd(IBM), Sanjiva Weerawarana(IBM), Roger Wolter(Microsoft).

2139 The following individuals were members of the committee during the development of this specification:

2140 Abbie Barbir(Nortel), Charlton Barreto(Adobe), Stefan Batres(Microsoft), Hamid Ben Malek 2141 (Fujitsu), Andreas Bjarlestam(Ericsson), Toufic Boubez(Layer 7), Doug Bunting(Sun), Lloyd Burch 2142 (Novell), Steve Carter(Novell), Martin Chapman(Oracle), Dave Chappell(Sonic), Paul Cotton 2143 (Microsoft), Glen Daniels(Sonic), Doug Davis(IBM), Blake Dournaee(Intel), Jacques Durand 2144 (Fujitsu), Colleen Evans(Microsoft), Christopher Ferris(IBM), Paul Fremantle(WSO2), Robert 2145 Freund(Hitachi), Peter Furniss(Erebor), Marc Goodner(Microsoft), Alastair Green(Choreology), 2146 Mike Grogan(Sun), Ondrej Hrebicek(Microsoft), Kazunori Iwasa(Fujitsu), Chamikara Jayalath 2147 (WSO2), Lei Jin(BEA), Ian Jones(BTplc), Anish Karmarkar(Oracle), Paul Knight(Nortel), Dan 2148 Leshchiner(Tibco), Mark Little(JBoss), Lily Liu(webMethods), Matt Lovett(IBM), Ashok Malhotra 2149 (Oracle), Jonathan Marsh(Microsoft), Daniel Millwood(IBM), Jeff Mischkinsky(Oracle), Nilo Mitra 2150 (Ericsson), Peter Niblett(IBM), Duane Nickull(Adobe), Eisaku Nishiyama(Hitachi), Dave Orchard 2151 (BEA), Chouthri Palanisamy(NEC), Sanjay Patil(SAP), Gilbert Pilz(BEA), Martin Raepple(SAP), 2152 Eric Rajkovic(Oracle), Stefan Rossmanith(SAP), Tom Rutt(Fujitsu), Rich Salz(IBM), Shivajee 2153 Samdarshi(Tibco), Vladimir Videlov(SAP), Claus von Riegen(SAP), Pete Wenzel(Sun), Steve 2154 Winkler(SAP), Ümit Yalçinalp(SAP), Nobuyuki Yamamoto(Hitachi).

**Appendix F. Revision History**
Rev	Date	By Whom	What
wd-01	2005-07-07	Christopher Ferris	Initial version created based on submission by the authors.
ws-02	2005-07-21	Doug Davis	I011 (PT0S) added
wd-02	2005-08-16	Anish Karmarkar	Trivial editorial changes
ws-03	2005-09-15	Doug Davis	I019 and i028 (CloseSeq) added
wd-05	2005-09-26	Gilbert Pilz	i005 (Source resend of nacks messages when ack already received) added.
wd-05	2005-09-27	Doug Davis	i027 (InOrder delivery assurance spanning multiple sequences) added
wd-05	2005-09-27	Doug Davis	i020 (Semantics of “At most once” Delivery Assurance) added
wd-05	2005-09-27	Doug Davis	i034 (Fault while processing a piggy-backed RM header) added
wd-05	2005-09-27	Doug Davis	i033 (Processing model of NACKs) added
wd-05	2005-09-27	Doug Davis	i031 (AckRequested schema inconsistency) added
wd-05	2005-09-27	Doug Davis	i025 (SeqAck/None) added
wd-05	2005-09-27	Doug Davis	i029 (Remove dependency on WS-Security) added
wd-05	2005-09-27	Doug Davis	i039 (What does 'have a mU attribute' mean) added
wd-05	2005-09-27	Doug Davis	i040 (Change 'optiona'/'required' to 'OPTIONAL'/'REQUIRED') added
wd-05	2005-09-30	Anish Karmarkar	i017 (Change NS to http://docs.oasisopen.org/wsrm/200510/)
wd-05	2005-09-30	Anish Karmarkar	i045 (Include SecureConversation as a reference and move it to non-normative citation)
wd-05	2005-09-30	Anish Karmarkar	i046 (change the type of wsrm:FaultCode element)
wd-06	2005-11-02	Gilbert Pilz	Start wd-06 by changing title page from cd-01.
wd-06	2005-11-03	Gilbert Pilz	i047 (Reorder spec sections)
wd-07	2005-11-17	Gilbert Pilz	Start wd-07
wd-07	2005-11-28	Doug Davis	i071 – except for period in Appendix headings
wd-07	2005-11-28	Doug Davis	i10
wd-07	2005-11-28	Doug Davis	i030
wd-07	2005-11-28	Doug Davis	i037
wd-07	2005-11-28	Doug Davis	i038
wd-07	2005-11-28	Doug Davis	i041
wd-07	2005-11-28	Doug Davis	i043
wd-07	2005-11-28	Doug Davis	i044

Rev	Date	By Whom	What
wd-07	2005-11-28	Doug Davis	i048
wd-07	2005-11-28	Doug Davis	i051
wd-07	2005-11-28	Doug Davis	i053
wd-07	2005-11-28	Doug Davis	i059
wd-07	2005-11-28	Doug Davis	i062
wd-07	2005-11-28	Doug Davis	i063
wd-07	2005-11-28	Doug Davis	i065
wd-07	2005-11-28	Doug Davis	i067
wd-07	2005-11-28	Doug Davis	i068
wd-07	2005-11-28	Doug Davis	i069
wd-07	2005-11-28	Doug Davis	Fix bulleted list (#2) in section 2.3
wd-07	2005-11-29	Gilbert Pilz	i074 (Use of [tcShortName] in artifact locations namespaces, etc)
wd-07	2005-11-29	Gilbert Pilz	i071 – Fixed styles and formating for TOC. Fixed styles of the appendix headings.
wd-07	2005-11-30	Doug Davis	Removed dup definition of "Receive"
wd-07	2005-11-30	Gilbert Pilz	Fixed lost formatting from heading for Namespace section. Fixed style of text body elements to match OASIS example documents. Fixed tables to match OASIS example documents.
wd-07	2005-12-01	Gilbert Pilz	Updated fix for i074 to eliminate trailing '/'. Added corresponding text around action IRI composition.
wd-07	2005-12-01	Gilbert Pilz	Use non-fixed fields for date values on both title page and body footers.
wd-07	2005-12-01	Doug Davis	Alphabetize the glossary
wd-07	2005-12-02	Doug Davis	i064
wd-07	2005-12-02	Doug Davis	i066
wd-08	2005-12-15	Doug Davis	Add back in RM Source to glossary
wd-08	2005-12-15	Steve Winkler	Doug added Steve's editorial nits
wd-08	2005-12-21	Doug Davis	i050
wd-08	2005-12-21	Doug Davis	i081
wd-08	2005-12-21	Doug Davis	i080 – but i050 negates the need for any changes
wd-08	2005-12-21	Doug Davis	i079
wd-08	2005-12-21	Doug Davis	I076 – didn't add text about "replies" since the RMD to RMS sequence could be used for any message not just replies
wd-08	2005-12-21	Umit Yalcinalp	Action Su03: removed wsse from Table 1
wd-08	2005-12-21	Umit Yalcinalp	I057 per Sunnyvale F2F 2005, Cleaned up some formatting errors in contributors
wd-08	2005-12-27	Doug Davis	i060

Rev	Date	By Whom	What
wd-08	2005-12-27	Gilbert Pilz	Moved schema and WSDL files to their own artifacts. Converted source document to OpenDocument Text format. Changed line numbers to be a single style.
wd-08	2005-12-28	Anish Karmarkar	Included a section link to c:\temp\wsrm-1.1schema-200510.xsd and to c:\temp\wsrm-1.1wsdl-200510.wsdl
wd-08	2006-01-04	Gilbert Pilz	Fixed formatting for included sections.
wd-08	2006-01-05	Gilbert Pilz	Created links for unused references. Fixed exemplars for CloseSequence and CloseSequenceResponse.
wd-09	2006-01-11	Doug Davis	Minor tweaks to text/typos.
wd-10	2006-01-23	Doug Davis	Accept all changes from wd-09 Make some minor editoral tweaks from Marc's comments.
wd-10	2006-02-14	Doug Davis	Issue 082 resolution
wd-10	2006-02-14	Doug Davis	Issue 083 resolution
wd-10	2006-02-14	Doug Davis	Issue 085 resolution
wd-10	2006-02-14	Doug Davis	Issues 086, 087 resolutions Defined MessageNumberType
wd-10	2006-02-15	Doug Davis	Issue 078 resolution
wd-10	2006-02-15	Doug Davis	Issue 094 resolution
wd-10	2006-02-15	Doug Davis	Issue 095 resolution
wd-10	2006-02-15	Gilbert Pilz	Issue 088 – added namespace URI link to namespace URI; added text explaining that this URI could be dereferenced to produce the RDDL doc; added non-normative reference to RDDL 2.0
wd-10	2006-02-17	Anish Karmarkar	Namespace changed to 200602 for both WSDL and XSD docs.
wd-10	2006-02-17	Anish Karmarkar	Issue i087 as it applies to WSRM spec.
wd-10	2006-02-17	Anish Karmarkar	Added titles and minor text for state table (issue i058).
wd-11	2006-02-22	Doug Davis	Accept all changes for new WD Minor typos fixed
wd-11	2006-02-23	Doug Davis	s/'close'/close/g – per Marc Goodner Added first ref to [URI] – per Marc G again
wd-11	2006-02-27	Doug Davis	Issue i061 applied
wd-11	2006-02-28	Doug Davis	Fixed typo around the use of "above" and "below"
wd-11	2006-03-01	Doug Davis	Minor typos found by Marc Goodner
wd-11	2006-03-02	Doug Davis	Minor typos found by Matt Lovett
wd-11	2006-03-08	Doug Davis	Issue 091 applied
wd-11	2006-03-08	Doug Davis	Issue 092 applied

Rev	Date	By Whom	What
wd-11	2006-03-08	Doug Davis	Issue 100 applied
wd-12	2006-03-20	Doug Davis	Added space in "SOAP1.x" – PaulCotton
wd-12	2006-04-11	Doug Davis	Issue 007 applied
wd-12	2006-04-11	Doug Davis	Issue 090 applied
wd-12	2006-04-11	Doug Davis	Issue 098 applied
wd-12	2006-04-11	Doug Davis	Issue 099 applied
wd-12	2006-04-11	Doug Davis	Issue 101 applied
wd-12	2006-04-11	Doug Davis	Issue 103 applied
wd-12	2006-04-11	Doug Davis	Issue 104 applied
wd-12	2006-04-11	Doug Davis	Issue 105 applied
wd-12	2006-04-11	Doug Davis	Issue 107 applied
wd-12	2006-04-11	Doug Davis	Issue 109 applied
wd-12	2006-04-11	Doug Davis	Issue 110 applied
wd-12	2006-04-12	Doug Davis	Used "generated" instead of "issue" or "send" when talking about faults.
wd-12	2006-04-24	Gilbert Pilz	Update references to WS-Addressing to the Proposed Recommendations; update WS-RM namespace to “200604”.
wd-13	2006-05-08	Gilbert Pilz	i093 part 1; more work needed
wd-13	2006-05-10	Doug Davis	Issue 096 applied
wd-13	2006-05-26	Gilbert Pilz	i093 part 2; reflects decisions from 2006-05-25 meeting
wd-13	2006-05-28	Gilbert Pilz	Issue 106 applied
wd-13	2006-05-29	Gilbert Pilz	Issue 118 applied
wd-13	2006-05-29	Gilbert Pilz	Issue 120 applied
wd-13	2006-05-30	Gilbert Pilz	Issue 114 applied
wd-13	2006-05-30	Gilbert Pilz	Issue 116 applied
wd-14	2006-06-05	Gilbert Pilz	Accept all changes; bump WD number
wd-14	2006-06-07	Doug Davis	Applied lots of minor edits from Marc Goodner
wd-14	2006-06-07	Doug Davis	Change a couple of period/sp/sp to period/sp
wd-14	2006-06-07	Doug Davis	Added a space in "URI])of" – per Marc Goodner
wd-14	2006-06-07	Doug Davis	Issue 131 applied
wd-14	2006-06-07	Doug Davis	Issue 132 applied
wd-14	2006-06-07	Doug Davis	Issue 119 applied
wd-14	2006-06-07	Doug Davis	Applied lots of minor edits from Doug Davis
wd-14	2006-06-07	Doug Davis	s/"none"/"full-uri"/ - per Marc Goodner
wd-14	2006-06-12	Doug Davis	Complete i106
wd-14	2006-06-12	Doug Davis	Issues 089 applied
wd-14	2006-06-12	Doug Davis	Fix for several RFC2119 keywords – per Anish
wd-15	2006-06-12	Doug Davis	Accept all changed, dump WD number
wd-15	2006-06-12	Doug Davis	Move WSDL after Schema

Rev	Date	By Whom	What
wd-15	2006-06-12	Doug Davis	Nits – remove tabs, extra [yyy]'s ...
wd-15	2006-06-14	Doug Davis	Remove extra "OPTIONAL"s – Matt Lovett
wd-15	2006-06-14	Doug Davis	Remove blank rows/columns from state table. Fix italics in state table
wd-15	2006-06-15	Doug Davis	Typo – section D was empty
wd-15	2006-06-16	Doug Davis	Issue 125 applied
wd-15	2006-06-16	Doug Davis	Issue 126 applied
wd-15	2006-06-16	Doug Davis	Issue 127 applied
wd-15	2006-06-16	Doug Davis	Issue 133 applied
wd-15	2006-06-16	Doug Davis	Issue 136 applied
wd-15	2006-06-16	Doug Davis	Issue 138 applied
wd-15	2006-06-16	Doug Davis	Issue 135 applied
wd-15	2006-06-20	Doug Davis	Added all TC members to the ack list
wd-15	2006-06-22	Doug Davis	Issue 129 applied
wd-15	2006-06-22	Doug Davis	Issue 130 applied
wd-15	2006-06-22	Doug Davis	Issue 137 applied
wd-15	2006-06-26	Doug Davis	Issue 111 applied
wd-15	2006-06-26	Doug Davis	Missed a part of issue 129
wd-15	2006-06-30	Doug Davis	Fixed a typo in schema
wd-15	2006-06-30	Doug Davis	Issue 141 applied
wd-15	2006-06-30	Doug Davis	Issue 142 applied
wd-15	2006-06-30	Doug Davis	Issue 148 applied
wd-15	2006-06-30	Doug Davis	Issue 149 applied
wd-15	2006-06-30	Doug Davis	Issue 150 applied
wd-15	2006-07-06	Doug Davis	Issue 121 applied
wd-15	2006-07-21	Doug Davis	Issue 139 applied
wd-15	2006-07-21	Doug Davis	Issue 144 applied
wd-15	2006-07-21	Doug Davis	Issue 147 applied
wd-15	2006-07-21	Doug Davis	Issues 122-124 applied
wd-15	2006-07-27	Doug Davis	Updated list of oasis TC members (i134)
wd-15	2006-07-27	Doug Davis	Issue 140 applied
wd-15	2006-07-27	Doug Davis	Issue 145 applied
wd-15	2006-07-27	Doug Davis	Issue 143 applied
wd-15	2006-07-28	Doug Davis	Lots of minor typos found by Matt L.
wd-15	2006-07-28	Doug Davis	Issue 113 applied
wd-15	2006-08-04	Doug Davis	Update old namespaces – found by PaulC
wd-15	2006-08-04	Doug Davis	Issue 150 applied
wd-15	2006-08-04	Doug Davis	Minor typos – found by PeterN
wd-15	2006-08-04	Doug Davis	Verify all [refs]
wd-15	2006-08-04	Doug Davis	Change namespace to 2006/08
wd-15	2006-08-04	Doug Davis	Issue 148 applied

Rev	Date	By Whom	What
wd-15	2006-08-07	Doug Davis	Add some new glossary terms – per GilP
cd-04	2006-08-10	Gilbert Pilz	Formatting changes for better HTML rendering.
cd-04	2006-08-11	Doug Davis	Issue 158 applied
cd-04	2006-08-11	Doug Davis	Issue 153 applied
cd-04	2006-08-11	Doug Davis	Issue 156 applied
cd-04	2006-08-15	Gilbert Pilz	More formatting changes for better HTML rendering.
wd-16	2006-10-25	Doug Davis	Accept all changes, update to wd16
wd-16	2006-10-26	Doug Davis	PR002 applied
wd-16	2006-10-26	Doug Davis	PR003 applied
wd-16	2006-10-26	Doug Davis	PR004 applied
wd-16	2006-10-27	Doug Davis	PR005 applied
wd-16	2006-10-27	Doug Davis	PR006 applied
wd-16	2006-10-27	Doug Davis	PR024 applied
wd-16	2006-11-13	Doug Davis	PR010 applied
wd-16	2006-11-13	Doug Davis	PR011 applied (technically as part of PR004)
wd-16	2006-11-13	Doug Davis	PR016 applied
wd-16	2006-11-13	Doug Davis	PR032 applied
wd-16	2006-11-20	Doug Davis	PR025 applied
wd-16	2006-11-20	Doug Davis	PR023 applied
wd-16	2006-12-03	Doug Davis	PR036 applied
wd-16	2006-12-03	Doug Davis	PR017 applied
wd-16	2006-12-11	Doug Davis	PR012 applied (and PR013)
wd-16	2006-12-14	Doug Davis	PR033 applied – changed a 'return' to 'generate' when talking about a fault
wd-16	2007-01-04	Doug Davis	PR018 applied
wd-16	2007-01-05	Doug Davis	Moved MakeConnection to new spec
wd-16	2007-01-17	Doug Davis	PR026 applied
wd-16	2007-01-18	Doug Davis	PR021 applied
wd-16	2007-01-18	Doug Davis	PR022 applied
wd-16	2007-01-18	Doug Davis	Fixed a few typos (Doug,Gil)
wd-16	2007-01-18	Gilbert Pilz	PR007 applied
wd-16	2007-01-25	Doug Davis	PR039 applied
wd-17	2007-01-31	Doug Davis	Lots of typos from MarcG Updated WD number and date
wd-17	2007-02-01	Doug Davis	PR038 applied
wd-17	2007-02-01	Doug Davis	PR035 (009,020 dups) applied Fixed typo in state table

2156

Appendix G. Notices

2157 OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 2158 might be claimed to pertain to the implementation or use of the technology described in this document or 2159 the extent to which any license under such rights might or might not be available; neither does it represent 2160 that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to 2161 rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made 2162 available for publication and any assurances of licenses to be made available, or the result of an attempt 2163 made to obtain a general license or permission for the use of such proprietary rights by implementors or 2164 users of this specification, can be obtained from the OASIS Executive Director.

2165 OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or 2166 other proprietary rights which may cover technology that may be required to implement this specification. 2167 Please address the information to the OASIS Executive Director.

2169 This document and translations of it may be copied and furnished to others, and derivative works that 2170 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and 2171 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and 2172 this paragraph are included on all such copies and derivative works. However, this document itself may 2173 not be modified in any way, such as by removing the copyright notice or references to OASIS, except as 2174 needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights 2175 defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it 2176 into languages other than English.

2177 The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 2178 or assigns.

2179 This document and the information contained herein is provided on an "AS IS" basis and OASIS 2180 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2181 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2182 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Web Services Reliable Messaging