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