1
2
3
4
5 Document identifier:
6 wsrmp-1.1-spec-cwd-05114
7 Location:
8 http://docs.oasis-open.org/ws-rx/wsrmp/200608200702/wsrmp-1.1-spec-cwd-0511608/wsrmp9 1.1-spec-cd-04.pdf
10 Editors: 11 Doug Davis, IBM <dug@us.ibm.com> 12 Anish Karmarkar, Oracle <Anish.Karmarkar@oracle.com> 13 Gilbert Pilz, BEA <gpilz@bea.com> 14 Ümit Yalçinalp, SAP <umit.yalcinalp@sap.com>
15 Contributors: 16 See the Acknowledgments (Appendix A).
17 Abstract: 18 This specification describes a domain-specific policy assertion for WS-ReliableMessaging [WS 19 RM ] that that can be specified within a policy alternative as defined in WS-Policy Framework [WS 20 Policy].
21 By using the XML [ XML ], SOAP [SOAP 1.1], [ SOAP 1.2 ] and WSDL [WSDL 1.1] extensibility 22 models, the WS* specifications are designed to be composed with each other to provide a rich 23 Web services environment. This by itself does not provide a negotiation solution for Web services. 24 This is a building block that is used in conjunction with other Web service and application-specific 25 protocols to accommodate a wide variety of policy exchange models.
26 Status: 27 This document was last revised or approved by the WS-RX on the above date. The level of 28 approval is also listed above. Check the current location noted above for possible later revisions 29 of this document. This document is updated periodically on no particular schedule. Technical 30 Committee members should send comments on this specification to the Technical Committee's 31 email list. Others should send comments to the Technical Committee by using the "Send A 32 Comment" button on the Technical Committee's web page at http://www.oasis 33 open.org/committees/ws-rx. For information on whether any patents have been disclosed that 34 may be essential to implementing this specification, and any offers of patent licensing terms, 35 please refer to the Intellectual Property Rights section of the Technical Committee web page 36 (http://www.oasis-open.org/committees/ws-rx/ipr.php). The non-normative errata page for this 37 specification is located at http://www.oasis-open.org/committees/ws-rx.
38
43 1.4 Compliance........................................................................................................................................ 4 44 2 RM Policy Assertions................................................................................................................................ 5
49 2.5 Sequence Security Policy.................................................................................................................. 8 50 3 Security Considerations.......................................................................................................................... 10 51 4 References............................................................................................................................................. 11
53 4.2 Non Normative................................................................................................................................. 12 54 Appendix A. Acknowledgments.................................................................................................................. 13 55 Appendix B. XML Schema......................................................................................................................... 14 56 Appendix C. Revision History..................................................................................................................... 16 57 Appendix D. Notices................................................................................................................................... 19
58
59 This specification defines a domain-specific policy assertion for reliable messaging for use with WS-Policy 60 and WS-ReliableMessaging.
64 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 65 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described 66 in RFC 2119 [KEYWORDS].
67 This specification uses the following syntax to define normative outlines for messages:
68 • The syntax appears as an XML instance, but values in italics indicate data types instead of values.
69 • Characters are appended to elements and attributes to indicate cardinality:
70 o "?" (0 or 1)
71 o "*" (0 or more)
72 o "+" (1 or more)
73 • The character "|" is used to indicate a choice between alternatives.
74 • The characters "[" and "]" are used to indicate that contained items are to be treated as a group 75 with respect to cardinality or choice.
76 • An ellipsis (i.e. "...") indicates a point of extensibility that allows other child, or attribute, content. 77 Additional children and/or attributes MAY be added at the indicated extension points but MUST 78 NOT contradict the semantics of the parent and/or owner, respectively. If an extension is not 79 recognized it SHOULD be ignored.
80 • XML namespace prefixes (See Section 1.3) are used to indicate the namespace of the element 81 being defined.
82 Elements and Attributes defined by this specification are referred to in the text of this document using 83 XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this 84 syntax:
85 • An element extensibility point is referred to using {any} in place of the element name. This 86 indicates that any element name can be used, from any namespace other than the wsrm: 87 namespace.
88 • An attribute extensibility point is referred to using @{any} in place of the attribute name. This 89 indicates that any attribute name can be used, from any namespace other than the wsrm: 90 namespace.
wsrmp-1.1-spec-cd-05 11 AugustFebruary 20067
Copyright © OASIS Open 20067. All Rights Reserved. Page 3 of 23
92 The XML namespace [XML-ns] URI that MUST be used by implementations of this specification is:
94 Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0] 95 document that describes this namespace.
96 Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix
97 is arbitrary and not semantically significant.
98 Table 1
wsdl http://schemas.xmlsoap.org/wsdl/ wsp http://schemas.xmlsoap.org/ws/2004/09/policy wsrmp http://docs.oasis-open.org/ws
rx/wsrmp/200608200702 wsu http://docs.oasis-open.org/wss/2004/01/oasis-200401wss-wssecurity-utility-1.0.xsd
[WSDL 1.1] [WS-Policy] This specification.
WS-Security-Utility Schema
100 An implementation is not compliant with this specification if it fails to satisfy one or more of the MUST or 101 REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace 102 identifier for this specification (listed in Section 1.3) within SOAP Envelopes unless it is compliant with this 103 specification.
104 Normative text within this specification takes precedence over normative outlines, which in turn take 105 precedence over the XML Schema [XML-Schema Part1, XML-Schema Part2] descriptions.
106
2 RM Policy Assertions
107 WS-Policy Framework and WS-Policy Attachment [WS-PolicyAttachment] collectively define a framework, 108 model and grammar for expressing the requirements, and general characteristics of entities in an XML 109 Web services-based system. To enable an RM Destination and an RM Source to describe their 110 requirements for a given Sequence, this specification defines a single RM policy assertion that leverages 111 the WS-Policy framework.
112 2.1 Assertion Model
113 The RM policy assertion indicates that the RM Source and RM Destination MUST use WS114 ReliableMessaging to ensure reliable delivery of messages. Specifically, the WS-ReliableMessaging 115 protocol determines invariants maintained by the reliable messaging endpoints and the directives used to 116 track and manage the delivery of a Sequence of messages.
117 2.2 Normative Outline 118 The normative outline for the RM assertion is:
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133
134 The following describes the content model of the RMAssertion element.additional, normative constraints 135 on the outline listed above:
136 /wsrmp:RMAssertion 137 A policy assertion that specifies that WS-ReliableMessaging protocol MUST be used when 138 sending messages.
139 /wsrmp:RMAssertion/@wsp:Optional="true" 140 Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the 141 assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, 142 that WS-ReliableMessaging MAY be used.
143 /wsrmp:RMAssertion/wsp:Policy 144 This required element allows for the inclusion of nested policy assertions.
145 /wsrmp:RMAssertion/wsp:Policy/wsrmp:SequenceSTR
146 When present, this assertion defines the requirement that an RM Sequence MUST be bound to 147 an explicit token that is referenced from a wsse:SecurityTokenReference in the CreateSequence 148 message. See section 2.5.1.
149 /wsrmp:RMAssertion/wsp:Policy/wsrmp:SequenceTransportSecurity
150 When present, this assertion defines the requirement that an RM Sequence MUST be bound to 151 the session(s) of the underlying transport-level protocol used to carry the CreateSequence and 152 CreateSequenceResponse message. See section 2.5.2.
153 /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance
154 This expression, which may be omitted, describes the message delivery quality of service 155 between the RM and application layer. When used by an RM Destination it expresses the delivery 156 assurance in effect between the RM Destination and its corresponding application destination, 157 and it also indicates requirements on any RM Source that transmits messages to this RM 158 destination. Conversely when used by an RM Source it expresses the delivery assurance in effect 159 between the RM Source and its corresponding application source, as well as indicating 160 requirements on any RM Destination that receives messages from this RM Source. In either case 161 the delivery assurance does not affect the messages transmitted on the wire. Absence of this 162 expression from a wsrmp:RMAssertion policy assertion simply means that the endpoint has 163 chosen not to advertise its delivery assurance characteristics. 164 Note that when there are multiple policy alternatives of the RM Assertion, the Delivery Assurance 165 on each MUST NOT conflict.
166 /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy
167 This required element identifies additional requirements for the use of the 168 wsrmp:DeliveryAssurance.
169 /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:ExactlyOnce
170 This expresses the ExactlyOnce Delivery Assurance defined in [] .
171 /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:AtLeastOnce
172 This expresses the AtLeastOnce Delivery Assurance defined in [] .
173 /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:AtMostOnce
174 This expresses the AtMostOnce Delivery Assurance defined in [] .
175 /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:InOrder
176 This expresses the InOrder Delivery Assurance defined in [] .
177 /wsrmp:RMAssertion/{any}
178 This is an extensibility mechanism to allow different (extensible) types of information, based on a 179 schema, to be passed.
180 /wsrmp:RMAssertion/@{any}
181 This is an extensibility mechanism to allow different (extensible) types of information, based on a 182 schema, to be passed.
183 2.3 Assertion Attachment
184 The RM policy assertion is allowed to have the following Policy Subjects [WS-PolicyAttachment]:
185 ● Endpoint Policy Subject
wsrmp-1.1-spec-cd-05 11 AugustFebruary 20067 Copyright © OASIS Open 20067. All Rights Reserved. Page 6 of 23
186 ● Message Policy Subject 187 WS-PolicyAttachment defines a set of WSDL/1.1 policy attachment points for each of the above Policy 188 Subjects. Since an RM policy assertion specifies a concrete behavior, it MUST NOT be attached to the 189 abstract WSDL policy attachment points. 190 The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an 191 RM policy assertion but which MUST NOT have RM policy assertions attached: 192 • wsdl:message 193 • wsdl:portType/wsdl:operation/wsdl:input 194 • wsdl:portType/wsdl:operation/wsdl:output 195 • wsdl:portType/wsdl:operation/wsdl:fault 196 • wsdl:portType 197 The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an 198 RM policy assertion and which MAY have RM policy assertions attached: 199 • wsdl:port 200 • wsdl:binding 201 • wsdl:binding/wsdl:operation/wsdl:input 202 • wsdl:binding/wsdl:operation/wsdl:output 203 • wsdl:binding/wsdl:operation/wsdl:fault 204 If an RM policy assertion is attached to any of: 205 • wsdl:binding/wsdl:operation/wsdl:input 206 • wsdl:binding/wsdl:operation/wsdl:output 207 • wsdl:binding/wsdl:operation/wsdl:fault 208 then an RM policy assertion, specifying wsp:Optional=true MUST be attached to the corresponding 209 wsdl:binding or wsdl:port, indicating that the endpoint supports WS-RM. Any messages, regardless of 210 whether they have an attached Message Policy Subject RM policy assertion, MAY be sent to that endpoint 211 using WS-RM. Additionally, the receiving endpoint MUST NOT reject any message belonging to a 212 Sequence, simply because there was no Message Policy Subject RM policy assertion attached to that 213 message. There might be certain RM implementations that are incapable of applying RM Quality of 214 Service (QoS)oS semantics on a per-message basis. In order to ensure the broadest interoperability, 215 when an endpoint decorates its WSDL with RM policy assertions using Message Policy Subject, it MUST 216 also be prepared to accept that all messages sent to that endpoint might be sent within the context of an 217 RM Sequence, regardless of whether the corresponding wsdl:input, wsdl:output or wsdl:fault had an 218 attached RM policy assertion. 219 Rather than turn away messages that were unnecessarily sent with RM semantics, the receiving endpoint 220 described by the WSDL MUST accept these messages. 221 By attaching an RM policy assertion that specifies wsp:Optional="true" to the corresponding endpoint that 222 has attached RM policy assertions at the Message Policy Subject level, the endpoint is describing the 223 above constraint in policy. 224 In the case where an optional RM Assertion applies to an output message, there is no requirement on the 225 client to support an RM Destination implementation
226 2.4 Assertion Example
227 Table 2 lists an example use of the RM policy assertion. 228 Table 2: Example policy with RM policy assertion
229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258
259 Line (09) in Table 2 indicates that WS-Policy is in use as a required extension.
260 Lines (11-16) are a policy expression that includes a RM policy assertion (lines 12-144) are a policy 261 expression that includes a RM policy assertion (Line 12) to indicate that WS-ReliableMessaging must be 262 used.
263 Lines (20-23) are a WSDL binding. Line (21) indicates that the policy in lines (11-1618-21) are a WSDL 264 binding. Line (19) indicates that the policy in Lines (11-14) applies to this binding, specifically indicating 265 that WS-ReliableMessaging must be used over all the messages in the binding.
267 WS-SecurityPolicy [SecurityPolicy] provides a framework and grammar for expressing the security 268 requirements and characteristics of entities in a XML web services based system. The following 269 assertions MAY be used in conjunction with WS-SecurityPolicy to express additional security 270 requirements particular to RM Sequences.
272 This version of the RM assertion includassertion defines the requirement that an RM Sequence MUST be 273 bound to an explicit token that is referenced from a wsse:SecurityTokenReference in the 274 CreateSequence message.
275 This assertion MUST apply to [Endpoint Policy Subject]. The normative outline for this form of the 276 Sequence STR Assertion is:is assertion MUST NOT be used for an endpoint that does not also use the 277 RM assertion.
278 279 280 281 282
283 The following describes the content model of the SequenceSTR element. 284 The normative outline for the Sequence STR Assertion is:
286 /wsrmp:SequenceSTR 287 A policy assertion that specifies security requirements which MUST be used with an RM Sequence that 288 are particular to WS-RM and beyond what can be expressed in WS-SecurityPolicy.
290 This version of the RM assertion includes the requirement that an RM Sequence MUST be bound to the 291 session(s) of the underlying transport-level security protocol (e.g. SSL/TLS) used to carry the 292 CreateSequence and CreateSequenceResponse messages.
293 This assertion MUST apply to [Endpoint Policy Subject]. This assertion is effectively meaningless unless it 294 occurs in conjunction with the sp:TransportBinding assertion that requires the use of some transport295 level security mechanism (e.g. sp:HttpsToken).
296 The normative outline for this form of the RM Assertion with the Sequence Transport Security Assertion is:
297 298 299 300 301 302 303 304 305 306 307 308 309 310
311 The following describes the content model of the SequenceTransportSecurity element.
312 /wsrm:SequenceSTR /@wsp:Optional="true"
313 Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion. 314 The intuition is that the behavior indicated by the assertion is optional, or in this case, that the RM 315 Sequence binding to a specific token MAY be used.
317 This assertion defines the requirement that an RM Sequence MUST be bound to the session(s) of the 318 319 underlying transport-level security protocol (e.g. SSL/TLS) used to carry the CreateSequence and CreateSequenceResponse messages.
320 This assertion MUST apply to [Endpoint Policy Subject]. This assertion is effectively meaningless unless it 321 322 occurs in conjunction with the RMAssertion and a sp:TransportBinding assertion that requires the use of some transport-level security mechanism (e.g. sp:HttpsToken).
323 The normative outline for the Sequence Transport Security Assertion is:
325 /wsrmp:SequenceTransportSecurity 326 A policy assertion that specifies that any Sequences targeted to the indicated endpoint MUST be bound to 327 the underlying session(s) of the transport-level security used to carry messages related to the Sequence.
328 This form of the RM Assertion says that an endpoint MAY have RM as an option but always requires 329 HTTPS to be used. All the SequenceTransportSecurity assertion indicates is that RM's rules for protecting 330 the Sequence over TLS are followed.
331 /wsrmp:SequenceTransportSecurity /@wsp:Optional="true332 "
Per WS-Policy, this is compact notation for two policy alternatives, one with and one without the assertion333 .
The meaning is that the behavior indicated by the assertion is optional, or in this case, that the binding o334 f
RM Sequences to transport-level security sessions MAY be used.
335
336 It is strongly RECOMMENDED that policies and assertions be signed to prevent tampering.
337 It is RECOMMENED that policies SHOULD NOT be accepted unless they are signed and have an 338 associated security token to specify the signer has proper claims for the given policy. That is, a relying 339 party shouldn't rely on a policy unless the policy is signed and presented with sufficient claims to pass the 340 relying parties acceptance criteria.
341 It should be noted that the mechanisms described in this document could be secured as part of a SOAP 342 message using WS-Security [WS-Security] or embedded within other objects using object-specific 343 security mechanisms.
344
345 4.1 Normative 346 [KEYWORDS] 347 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, 348 March 1997.
349 http://www.ietf.org/rfc/rfc2119.txt
352 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
355 http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
356 [URI] 357 T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 3986, 358 MIT/LCS, U.C. Irvine, Xerox Corporation, January 2005.
359 http://ietf.org/rfc/rfc3986
360 [WS-RM]
361
OASIS WS-RX Technical Committee Draft, "Web Services Reliable Messaging (WS-ReliableMessaging),"
362 AugustSeptember 2005.
363
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-0
5.pdf
4
364 [WS-Policy] 365 W3C Member Submission, "Web Services Policy Framework (WS-Policy)," April 2006.
366 http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/
367 [WS-PolicyAttachment] 368 W3C Member Submission, "Web Services Policy Attachment (WS-PolicyAttachment)," April 2006.
369 http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment 370 20060425/
373 http://www.w3.org/TR/2001/NOTE-wsdl-20010315
374 [XML]
375 W3C Recommendation, "
Extensible Markup Language (XML) 1.0 (
Fourth Edition)", September
376 2006
.
Second Edition)", October 2000
377 http://www.w3.org/TR/REC-xml/
378 [XML-ns] 379 W3C Recommendation, "Namespaces in XML," 14 January 1999.
380
http://www.w3.org/TR/1999/REC-xml-names-19990114/
381 [XML-Schema Part1]
382
W3C Recommendation, "XML Schema Part 1: Structures,"
October 20042 May 2001.
383
http://www.w3.org/TR/xmlschema-1/
384 [XML-Schema Part2]
385
W3C Recommendation, "XML Schema Part 2: Datatypes,"
October 20042 May 2001.
386 http://www.w3.org/TR/xmlschema-2/ 387 [XPATH 1.0] 388 W3C Recommendation, "XML Path Language (XPath) Version 1.0," 16 November 1999. 389 http://www.w3.org/TR/xpath
390 4.2 Non Normative 391 [RDDL 2.0] 392 Joh
nathan Borden, Tim Bray, eds. “Resource Directory Description Language (RDDL) 2.0,” January 2004
393 http://www.openhealth.org/RDDL/20040118/rddl-20040118.html 394 [SecurityPolicy] 395 G. Della-Libra, et. al. "Web Services Security Policy Language (WS-SecurityPolicy)", July 2005
396 http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf 397 [WS-Security] 398 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: 399 SOAP Message Security 1.0 (WS-Security 2004)", OASIS Standard 200401, March 2004. 400 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf 401 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: 402 SOAP Message Security 1.1 (WS-Security 2004)", OASIS Standard 200602, February 2006.
403 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1 404 spec-os-SOAPMessageSecurity.pdf
Appendix A. Acknowledgments
406 This document is based on initial contribution to OASIS WS-RX Technical Committee by the following 407 authors:
408 Stefan Batres-Editor(Microsoft), Ruslan Bilorusets(BEA), Don Box(Microsoft), Luis Felipe 409 Cabrera(Microsoft), Derek Collison(TIBCO Software), Donald Ferguson(IBM), Christopher Ferris410 Editor(IBM), Tom Freund(IBM), Mary Ann Hondo(IBM), John Ibbotson(IBM), Lei Jin(BEA), Chris 411 Kaler(Microsoft), David Langworthy(Microsoft), Amelia Lewis(TIBCO Software), Rodney 412 Limprecht(Microsoft), Steve Lucco(Microsoft), Don Mullen(TIBCO Software), Anthony 413 Nadalin(IBM), Mark Nottingham(BEA), David Orchard(BEA), Shivajee Samdarshi(TIBCO 414 Software), John Shewchuk(Microsoft), Tony Storey(IBM).
415 The following individuals have provided invaluable input into the initial contribution:
416 Keith Ballinger(Microsoft), Allen Brown(Microsoft), Michael Conner(IBM), Francisco 417 Curbera(IBM), Steve Graham(IBM), Pat Helland(Microsoft), Rick Hill(Microsoft), Scott 418 Hinkelman(IBM), Tim Holloway(IBM), Efim Hudis(Microsoft), Johannes Klein(Microsoft), Frank 419 Leymann(IBM), Martin Nally(IBM), Peter Niblett(IBM), Jeffrey Schlimmer(Microsoft), Chris 420 Sharp(IBM), James Snell(IBM), Keith Stobie(Microsoft), Satish Thatte(Microsoft), Stephen 421 Todd(IBM), Sanjiva Weerawarana(IBM), Roger Wolter(Microsoft).
422 The following individuals were members of the committee during the development of this specification:
423 Abbie Barbir(Nortel), Charlton Barreto(Adobe), Stefan Batres(Microsoft), Hamid Ben 424 Malek(Fujitsu), Andreas Bjarlestam(Ericsson), Toufic Boubez(Layer 7), Doug Bunting(Sun), Lloyd 425 Burch(Novell), Steve Carter(Novell), Martin Chapman(Oracle), Dave Chappell(Sonic), Paul 426 Cotton(Microsoft), Glen Daniels(Sonic), Doug Davis(IBM), Blake Dournaee(Intel), Jacques 427 Durand(Fujitsu), Colleen Evans(Microsoft), Christopher Ferris(IBM), Paul Fremantle(WSO2), 428 Robert Freund(Hitachi), Peter Furniss(Erebor), Marc Goodner(Microsoft), Alastair 429 Green(Choreology), Mike Grogan(Sun), Ondrej Hrebicek(Microsoft), Kazunori Iwasa(Fujitsu), 430 Chamikara Jayalath(WSO2), Lei Jin(BEA), Ian Jones(BTplc), Anish Karmarkar(Oracle), Paul 431 Knight(Nortel), Dan Leshchiner(Tibco), Mark Little(JBoss), Lily Liu(webMethods), Matt 432 Lovett(IBM), Ashok Malhotra(Oracle), Jonathan Marsh(Microsoft), Daniel Millwood(IBM), Jeff 433 Mischkinsky(Oracle), Nilo Mitra(Ericsson), Peter Niblett(IBM), Duane Nickull(Adobe), Eisaku 434 Nishiyama(Hitachi), Dave Orchard(BEA), Chouthri Palanisamy(NEC), Sanjay Patil(SAP), Gilbert 435 Pilz(BEA), Martin Raepple(SAP), Eric Rajkovic(Oracle), Stefan Rossmanith(SAP), Tom 436 Rutt(Fujitsu), Rich Salz(IBM), Shivajee Samdarshi(Tibco), Vladimir Videlov(SAP), Claus von 437 Riegen(SAP), Pete Wenzel(Sun), Steve Winkler(SAP), Ümit Yalçinalp(SAP), Nobuyuki 438 Yamamoto(Hitachi).
439
Appendix B. XML Schema
440 A normative copy of the XML Schema [ XML-Schema Part1 , XML-Schema Part2] description for this 441 specification may be retrieved from the following address:
442
http://docs.oasis-open.org/ws-rx/wsrmp/
200702/wsrmp-1.1-schema
443
200608
200702200608
.xsd
608/wsrmp-1.1-schema-200608
444 The following copy is provided for reference.
445 <?xml version="1.0" encoding="UTF-8"?>446 <!--447 OASIS takes no position regarding the validity or scope of any448 intellectual property or other rights that might be claimed to pertain to449 the implementation or use of the technology described in this document or450 the extent to which any license under such rights might or might not be451 available; neither does it represent that it has made any effort to452 identify any such rights. Information on OASIS's procedures with respect453 to rights in OASIS specifications can be found at the OASIS website.454 Copies of claims of rights made available for publication and any455 assurances of licenses to be made available, or the result of an attempt456 made to obtain a general license or permission for the use of such457 proprietary rights by implementors or users of this specification, can be458 obtained from the OASIS Executive Director. 459 OASIS invites any interested party to bring to its attention any460 copyrights, patents or patent applications, or other proprietary rights461 which may cover technology that may be required to implement this462 specification. Please address the information to the OASIS Executive463 Director. 464 Copyright (c) OASIS Open 2002-20067. All Rights Reserved.465 This document and translations of it may be copied and furnished to466 others, and derivative works that comment on or otherwise explain it or467 assist in its implementation may be prepared, copied, published and468 distributed, in whole or in part, without restriction of any kind,469 provided that the above copyright notice and this paragraph are included470 on all such copies and derivative works. However, this document itself471 does not be modified in any way, such as by removing the copyright notice472 or references to OASIS, except as needed for the purpose of developing473 OASIS specifications, in which case the procedures for copyrights defined474 in the OASIS Intellectual Property Rights document must be followed, or475 as required to translate it into languages other than English.476 The limited permissions granted above are perpetual and will not be477 revoked by OASIS or its successors or assigns.478 This document and the information contained herein is provided on an "AS479 IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,480 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
481 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
482 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
483 --> 484 <xs:schema xmlns:tns="http://docs.oasis-open.org/ws485 rx/wsrmp/200608200702" xmlns:xs="http://www.w3.org/2001/XMLSchema"486 targetNamespace="http://docs.oasis-open.org/ws-rx/wsrmp/2006082007026. 487 All Rights Reserved.488 This document and translations of it may be copied and furnished to489 others, and derivative works that comment on or otherwise explain it or490 assist in its implementation may be prepared, copied, published and491 distributed, in whole or in part, without restriction of any kind,492 provided that the above copyright notice and this paragraph are included493 on all such copies and derivative works. However, this document itself494 does not be modified in any way, such as by removing the copyright notice
495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532
533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561
Appendix C. Revision History
wd-01.doc 2005-07-06 Ümit Yalçinalp Initial version created based on submission by the authors.
1.0-wd-01.swx 2005-09-01 Ümit Yalçinalp Reformatted using Open Office
1.1-wd-01.swx 2005-09-18 Ümit Yalçinalp Applied resolution i001 Applied resolution i015/16 (doc identifier) Partial application of i017, final yyyy/mm required,
changed doc URI to TBD pending yyyy/mm Deleted original copyright section
1.1-wd-01.swx 2005-10-02 Anish Karmarkar Applied resolution of i013 + minor editorial changes + fixed resolution of i017
1.1-wd-01.swx 2005-10-04 Ümit Yalçinalp Applied actual value for yyyymm. Added resolution of i009
1.1-wd-01.swx 2005-10-06 Ümit Yalçinalp Editorial fixes suggested by Anish Updated wd draft date to October 6th
1.1-wd-01.swx 2005-10-19 Ümit Yalçinalp Editorial change to remove .sxw suffix from doc id
wd-02 2005-11-03 Gilbert Pilz Start wd-02 by changing title page from cd-01.
wd-02 2005-11-30 Gilbert Pilz i072 – editorial nits
wd-02 2005-11-30 Gilbert Pilz i074 -Use of [tcShortName] in artifact locations namespaces, etc
wd-02 2005-12-01 Gilbert Pilz Updated fix to i074 to remove trailing '/' from wsrmp namespace.
wd-02 2005-12-01 Anish Karmarkar Applied resolution for i022
wd-02 2005-12-01 Anish Karmarkar Applied resolution for i024
wd-02 2005-12-01 Anish Karmarkar Applied resolution for i054
wd-02 2005-12-01 Anish Karmarkar Applied resolution of i073
wd-2 2005-12-05 Anish Karmarkar Applied resolution of i055
wd-2 2005-12-05 Ümit Yalçinalp Changed fixed date in footer to current date
wd-3 2005-12-21 Doug Davis Added i050
wd-3 2005-12-23 Ümit Yalçinalp I057 resolution
wd-3 2005-12-23 Ümit Yalçinalp Changed the ref to WS-RM to the WS-RX committee
draft instead of original version Fixed Dug's email address
wd-3 2005-12-23 Ümit Yalçinalp I060 resolution
wd-03 2005-12-27 Gilbert Pilz Remove schema example and put it in its own artifact (wsrmp-1.1-schema-200510.xsd). Convert source file to OpenDocument format. Make line numbers all the same style.
wd-03 2005-12-28 Anish Karmarkar Included a section link to c:\temp\wsrmp-1.1-schema200510.xsd
wd-03 2006-01-04 Gilbert Pilz Fixed formatting of included section.
wd-03 2006-01-05 Gilbert Pilz Fix closing tag of normative outline for RMAssertion. wd-04 2006-11-11 Doug Davis Minor tweaks/typos
wd-05 2006-01-23 Gilbert Pilz Start wd-05 by accepting all changes from wd-04
wd-06 2006-01-23 Doug Davis Minor typos found by Marc
wd-06 2006-02-14 Doug Davis Issue 075 resolution
wd-06 2006-02-14 Doug Davis Issues 086, 087 resolutions
wd-06 2006-02-15 Gilbert Pilz Issue 088; added link for namespace URI; added text describing link; added non-normative reference for RDDL 2.0
wd-06 2006-02-17 Anish Karmarkar Removed a sentence in section 2.1 that talked about RM assertion parameters, as there aren't any.
wd-06 2006-02-17 Anish Karmarkar Change the namespace to 200602.
wd-07 2006-02-22 Doug Davis Accept all changes to create new WD Minor typo fixed – thanks to Paul Cotton
wd-07 2006-02-23 Doug Davis Added missing namespace table entries - MarcG
wd-07 2006-03-08 Doug Davis Issue 097 applied
wd-08 2006-04-11 Doug Davis Issue 021 applied
wd-08 2006-04-24 Gilbert Pilz Misc cleanups prior to publishing to TC.
wd-09 2006-05-29 Gilbert Pilz Issue 117 applied
wd-10 2006-06-05 Gilbert Pilz Accept all changes; bump WD number
wd-10 2006-06-07 Doug Davis Applied lots of minor edits from Marc Goodner
wd-10 2006-06-13 Doug Davis Applied a couple of minor edits
wd-10 2006-07-21 Doug Davis Issues 122-124 applied
wd-10 2006-07-27 Doug Davis Copied list of TC members from RM spec (i134)
wd-10 2006-08-04 Doug Davis Updated old namespaces – found by PaulC
wd-10 2006-08-04 Doug Davis Verify all [refs]
wd-10 2006-08-04 Doug Davis Change namespace to 2006/08
cd-04 2006-08-11 Doug Davis Issue 158 applied
cd-04 2006-08-16 Gilbert Pilz Fix date at 08/11/2006; formatting changes for better HTML rendering.
wd-11 2006-10-25 Doug Davis Accept all changes, update to wd11
wd-11 2006-10-26 Doug Davis PR004 applied
wd-11 2007-01-26 Doug Davis PR037 applied
wd-12 2007-01-31 Doug Davis Lots of typos from MarcG Updated WD number and date
wd-12 2007-02-01 Doug Davis PR035 (009,020 dups) applied
Revision Date By Whom What
wd-01.doc 2005-07-06 Ümit Yalçinalp Initial version created based on submission by the authors.
1.0-wd-01.swx 2005-09-01 Ümit Yalçinalp Reformatted using Open Office
1.1-wd-01.swx 2005-09-18 Ümit Yalçinalp Applied resolution i001 Applied resolution i015/16 (doc identifier) Partial application of i017, final yyyy/mm required,
changed doc URI to TBD pending yyyy/mm Deleted original copyright section
1.1-wd-01.swx 2005-10-02 Anish Karmarkar Applied resolution of i013 + minor editorial changes + fixed resolution of i017
1.1-wd-01.swx 2005-10-04 Ümit Yalçinalp Applied actual value for yyyymm. Added resolution of i009
1.1-wd-01.swx 2005-10-06 Ümit Yalçinalp Editorial fixes suggested by Anish Updated wd draft date to October 6th
1.1-wd-01.swx 2005-10-19 Ümit Yalçinalp Editorial change to remove .sxw suffix from doc id
wd-02 2005-11-03 Gilbert Pilz Start wd-02 by changing title page from cd-01.
wd-02 2005-11-30 Gilbert Pilz i072 – editorial nits
wd-02 2005-11-30 Gilbert Pilz i074 -Use of [tcShortName] in artifact locations namespaces, etc
wd-02 2005-12-01 Gilbert Pilz Updated fix to i074 to remove trailing '/' from wsrmp namespace.
wd-02 2005-12-01 Anish Karmarkar Applied resolution for i022
wd-02 2005-12-01 Anish Karmarkar Applied resolution for i024
wd-02 2005-12-01 Anish Karmarkar Applied resolution for i054
wd-02 2005-12-01 Anish Karmarkar Applied resolution of i073
wd-2 2005-12-05 Anish Karmarkar Applied resolution of i055
wd-2 2005-12-05 Ümit Yalçinalp Changed fixed date in footer to current date
wd-3 2005-12-21 Doug Davis Added i050
wd-3 2005-12-23 Ümit Yalçinalp I057 resolution
wd-3 2005-12-23 Ümit Yalçinalp Changed the ref to WS-RM to the WS-RX committee draft instead of original version
Fixed Dug's email address
wd-3 2005-12-23 Ümit Yalçinalp I060 resolution
wd-03 2005-12-27 Gilbert Pilz Remove schema example and put it in its own artifact (wsrmp-1.1-schema-200510.xsd). Convert source file to OpenDocument format. Make line numbers all the same style.
wd-03 2005-12-28 Anish Karmarkar Included a section link to c:\temp\wsrmp-1.1-schema200510.xsd
wd-03 2006-01-04 Gilbert Pilz Fixed formatting of included section.
wd-03 2006-01-05 Gilbert Pilz Fix closing tag of normative outline for RMAssertion. wd-04 2006-11-11 Doug Davis Minor tweaks/typos
wd-05 2006-01-23 Gilbert Pilz Start wd-05 by accepting all changes from wd-04
wd-06 2006-01-23 Doug Davis Minor typos found by Marc
wd-06 2006-02-14 Doug Davis Issue 075 resolution
wd-06 2006-02-14 Doug Davis Issues 086, 087 resolutions
wd-06 2006-02-15 Gilbert Pilz Issue 088; added link for namespace URI; added text describing link; added non-normative reference for RDDL 2.0
wd-06 2006-02-17 Anish Karmarkar Removed a sentence in section 2.1 that talked about RM assertion parameters, as there aren't any.
wd-06 2006-02-17 Anish Karmarkar Change the namespace to 200602.
wd-07 2006-02-22 Doug Davis Accept all changes to create new WD
Minor typo fixed – thanks to Paul Cotton
wd-07 2006-02-23 Doug Davis Added missing namespace table entries - MarcG
wd-07 2006-03-08 Doug Davis Issue 097 applied
wd-08 2006-04-11 Doug Davis Issue 021 applied
wd-08 2006-04-24 Gilbert Pilz Misc cleanups prior to publishing to TC.
wd-09 2006-05-29 Gilbert Pilz Issue 117 applied
wd-10 2006-06-05 Gilbert Pilz Accept all changes; bump WD number
wd-10 2006-06-07 Doug Davis Applied lots of minor edits from Marc Goodner
wd-10 2006-06-13 Doug Davis Applied a couple of minor edits
wd-10 2006-07-21 Doug Davis Issues 122-124 applied
wd-10 2006-07-27 Doug Davis Copied list of TC members from RM spec (i134)
wd-10 2006-08-04 Doug Davis Updated old namespaces – found by PaulC
wd-10 2006-08-04 Doug Davis Verify all [refs]
wd-10 2006-08-04 Doug Davis Change namespace to 2006/08
cd-04 2006-08-11 Doug Davis Issue 158 applied
cd-04 2006-08-16 Gilbert Pilz Fix date at 08/11/2006; formatting changes for better HTML rendering.
563
Appendix D. Notices
564 OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 565 might be claimed to pertain to the implementation or use of the technology described in this document or 566 the extent to which any license under such rights might or might not be available; neither does it represent 567 that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to 568 rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made 569 available for publication and any assurances of licenses to be made available, or the result of an attempt 570 made to obtain a general license or permission for the use of such proprietary rights by implementors or 571 users of this specification, can be obtained from the OASIS Executive Director.
572 OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or 573 other proprietary rights which may cover technology that may be required to implement this specification. 574 Please address the information to the OASIS Executive Director.
575 Copyright (C) OASIS Open (200676). All Rights Reserved.
576 This document and translations of it may be copied and furnished to others, and derivative works that 577 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and 578 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and 579 this paragraph are included on all such copies and derivative works. However, this document itself may 580 not be modified in any way, such as by removing the copyright notice or references to OASIS, except as 581 needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights 582 defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it 583 into languages other than English.
584 The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 585 or assigns.
586 This document and the information contained herein is provided on an "AS IS" basis and OASIS 587 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 588 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 589 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.