- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 22 Nov 2005 20:41:18 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv22083
Modified Files:
ws-addr-soap.xml
Log Message:
Added issue cr11 resolution, minor editorial teaks to SOAPAction to [action] relationship text
Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.104
retrieving revision 1.105
diff -C2 -d -r1.104 -r1.105
*** ws-addr-soap.xml 8 Nov 2005 05:21:03 -0000 1.104
--- ws-addr-soap.xml 22 Nov 2005 20:41:16 -0000 1.105
***************
*** 43,47 ****
<name>Tony Rogers</name>
<affiliation>Computer Associates International, Inc</affiliation>
! </author>
</authlist>
<abstract>
--- 43,47 ----
<name>Tony Rogers</name>
<affiliation>Computer Associates International, Inc</affiliation>
! </author>
</authlist>
<abstract>
***************
*** 142,148 ****
</tbody>
</table>
! <p>The Working Group intends to maintain the value of the &wsa-core.title; namespace
! URI that was assigned in the Candidate Recommendation unless significant changes are made
! that impact the implementation of the specification.</p>
<p>WS-Addressing is defined in terms of the XML Information Set [<bibref ref="XMLInfoSet"
/>]. WS-Addressing is conformant to the SOAP 1.2 [<bibref ref="SOAP12-PART1"/>] processing
--- 142,148 ----
</tbody>
</table>
! <p>The Working Group intends to maintain the value of the &wsa-core.title; namespace URI
! that was assigned in the Candidate Recommendation unless significant changes are made that
! impact the implementation of the specification.</p>
<p>WS-Addressing is defined in terms of the XML Information Set [<bibref ref="XMLInfoSet"
/>]. WS-Addressing is conformant to the SOAP 1.2 [<bibref ref="SOAP12-PART1"/>] processing
***************
*** 391,395 ****
binding[<bibref ref="SOAP12-PART2"/>] puts the reply message in the HTTP response.</p>
</div2>
-
</div1>
<div1 id="s11ext">
--- 391,394 ----
***************
*** 420,429 ****
<label>SOAP Action</label>
<def>
! <p>Use of the SOAPAction HTTP header is required when using the SOAP 1.1 HTTP binding.
! The value of the SOAPAction HTTP header MUST either be the value of the wsa:Action
! header enclosed in quotation marks, or the empty value "". The latter case supports
! the ability to obscure the wsa:Action header through SOAP-level security mechanisms,
! without requiring otherwise unnecessary transport-level security. Any other value
! for SOAPAction results in an Invalid Message Addressing Property fault (see <specref
ref="invalidmapfault"/>).</p>
</def>
--- 419,429 ----
<label>SOAP Action</label>
<def>
! <p>Use of the SOAPAction HTTP request header field is required when using the SOAP 1.1
! HTTP binding. The field-value of the SOAPAction HTTP request header MUST either be
! the value of the [action] property enclosed in quotation marks, or the empty value
! "". The latter case supports the ability to obscure the [action] property through
! SOAP-level security mechanisms, without requiring otherwise unnecessary
! transport-level security. Any other value for SOAPAction results in an Invalid
! Message Addressing Property fault (see <specref
ref="invalidmapfault"/>).</p>
</def>
***************
*** 434,439 ****
<div1 id="faults">
<head>Faults</head>
! <p>The faults defined in this section are generated if the condition stated in the
! preamble in each subsection is met.</p>
<p>Endpoints compliant with this specification MUST include the required message addressing
properties serialized as SOAP headers in generated fault messages. Fault messages are
--- 434,439 ----
<div1 id="faults">
<head>Faults</head>
! <p>The faults defined in this section are generated if the condition stated in the preamble in
! each subsection is met.</p>
<p>Endpoints compliant with this specification MUST include the required message addressing
properties serialized as SOAP headers in generated fault messages. Fault messages are
***************
*** 448,460 ****
&nsuri;/fault
</eg>
! <p>SOAP modules and extensions MAY define custom [action] values for the faults they
! describe or MAY designate use of the following [action] value instead:</p>
<eg xml:space="preserve">
&nsuri;/soap/fault
</eg>
! <p>The above [action] value SHOULD be used for generic SOAP faults including
! version mismatch, must understand, and data encoding unknown.</p>
! <p>Each of the predefined faults listed below is defined by specifying values
! for the following abstract properties:</p>
<p> [Code] The fault code, use of the specified fault code is REQUIRED.</p>
<p> [Subcode] The fault subcode, use of the specified fault subcode is REQUIRED.</p>
--- 448,460 ----
&nsuri;/fault
</eg>
! <p>SOAP modules and extensions MAY define custom [action] values for the faults they describe
! or MAY designate use of the following [action] value instead:</p>
<eg xml:space="preserve">
&nsuri;/soap/fault
</eg>
! <p>The above [action] value SHOULD be used for generic SOAP faults including version mismatch,
! must understand, and data encoding unknown.</p>
! <p>Each of the predefined faults listed below is defined by specifying values for the
! following abstract properties:</p>
<p> [Code] The fault code, use of the specified fault code is REQUIRED.</p>
<p> [Subcode] The fault subcode, use of the specified fault subcode is REQUIRED.</p>
***************
*** 463,468 ****
<p> [Reason] The English language reason element, use of the specified fault code is
RECOMMENDED but alternate text MAY be used.</p>
! <p> [Details] The detail elements, use of the specified detail elements is REQUIRED. If absent,
! no detail elements are defined for the fault.</p>
<div2>
<head>SOAP 1.2 Fault Binding</head>
--- 463,468 ----
<p> [Reason] The English language reason element, use of the specified fault code is
RECOMMENDED but alternate text MAY be used.</p>
! <p> [Details] The detail elements, use of the specified detail elements is REQUIRED. If
! absent, no detail elements are defined for the fault.</p>
<div2>
<head>SOAP 1.2 Fault Binding</head>
***************
*** 538,550 ****
<div2>
<head>SOAP 1.1 Fault Binding</head>
! <p>The SOAP 1.1 fault is slightly less expressive than the SOAP 1.2 fault and maps only [Subcode], [Reason] and
! [Detail]. These the properties bind to a SOAP 1.1 fault as follows:</p>
<glist>
<gitem>
<label>[Subcode] or [Subsubcode]</label>
<def>
! <p>The value of the [Subsubcode] or, if that is not specified, the value of the [Subcode]
! property is bound as the value of the SOAP faults
! S11:Fault/faultcode element.</p>
</def>
</gitem>
--- 538,551 ----
<div2>
<head>SOAP 1.1 Fault Binding</head>
! <p>The SOAP 1.1 fault is slightly less expressive than the SOAP 1.2 fault and maps only
! [Subcode], [Reason] and [Detail]. These the properties bind to a SOAP 1.1 fault as
! follows:</p>
<glist>
<gitem>
<label>[Subcode] or [Subsubcode]</label>
<def>
! <p>The value of the [Subsubcode] or, if that is not specified, the value of the
! [Subcode] property is bound as the value of the SOAP faults S11:Fault/faultcode
! element.</p>
</def>
</gitem>
***************
*** 561,566 ****
<p>The SOAP 1.1 fault detail is only for use with faults related to the body of a
message and is therefore not used for SOAP 1.1 faults related to processing of
! addressing headers. Instead the value of the [Details] property is bound as the value
! of a new wsa:FaultDetail SOAP header block. The following describes the
wsa:FaultDetail element:</p>
<glist>
--- 562,567 ----
<p>The SOAP 1.1 fault detail is only for use with faults related to the body of a
message and is therefore not used for SOAP 1.1 faults related to processing of
! addressing headers. Instead the value of the [Details] property is bound as the
! value of a new wsa:FaultDetail SOAP header block. The following describes the
wsa:FaultDetail element:</p>
<glist>
***************
*** 568,572 ****
<label>/wsa:FaultDetail</label>
<def>
! <p>Zero or more of the elements defined in <specref ref="faultdetailelements"/>.</p>
</def>
</gitem>
--- 569,574 ----
<label>/wsa:FaultDetail</label>
<def>
! <p>Zero or more of the elements defined in <specref ref="faultdetailelements"
! />.</p>
</def>
</gitem>
***************
*** 600,613 ****
</example>
</div2>
-
<div2 id="faultdetailelements">
<head>Fault Detail Elements</head>
<p>The following subsections define a set of elements used to convey additional information
! in the faults described in <specref ref="soapfaults"/>.</p>
<ednote>
<edtext>Additional detail elements may be defined if feedback during CR indicates that
this would be useful.</edtext>
</ednote>
-
<div3>
<head>Problem Header</head>
--- 602,613 ----
</example>
</div2>
<div2 id="faultdetailelements">
<head>Fault Detail Elements</head>
<p>The following subsections define a set of elements used to convey additional information
! in the faults described in <specref ref="soapfaults"/>.</p>
<ednote>
<edtext>Additional detail elements may be defined if feedback during CR indicates that
this would be useful.</edtext>
</ednote>
<div3>
<head>Problem Header</head>
***************
*** 618,622 ****
<def>
<p>The root element of the invalid header block, all descendants of the root element
! are also included.</p>
</def>
</gitem>
--- 618,622 ----
<def>
<p>The root element of the invalid header block, all descendants of the root element
! are also included.</p>
</def>
</gitem>
***************
*** 636,640 ****
<label>/wsa:ProblemHeaderQName</label>
<def>
! <p>A QName representing the name of the root element of the problem header block.</p>
</def>
</gitem>
--- 636,641 ----
<label>/wsa:ProblemHeaderQName</label>
<def>
! <p>A QName representing the name of the root element of the problem header
! block.</p>
</def>
</gitem>
***************
*** 703,708 ****
<def>
<p>This element (whose content is of type xs:unsignedLong) is a suggested minimum
! duration in milliseconds to wait before retransmitting the message. Omission of this
! element indicates that a retry is never likely to succeed.</p>
</def>
</gitem>
--- 704,709 ----
<def>
<p>This element (whose content is of type xs:unsignedLong) is a suggested minimum
! duration in milliseconds to wait before retransmitting the message. Omission of
! this element indicates that a retry is never likely to succeed.</p>
</def>
</gitem>
***************
*** 715,728 ****
</glist>
</div3>
-
</div2>
-
<div2 id="soapfaults">
<head>Predefined Faults</head>
<ednote>
! <edtext>Additional faults may be defined if feedback during CR indicates that
! this would be useful.</edtext>
</ednote>
-
<div3 id="invalidmapfault">
<head> Invalid Addressing Header</head>
--- 716,726 ----
</glist>
</div3>
</div2>
<div2 id="soapfaults">
<head>Predefined Faults</head>
<ednote>
! <edtext>Additional faults may be defined if feedback during CR indicates that this would
! be useful.</edtext>
</ednote>
<div3 id="invalidmapfault">
<head> Invalid Addressing Header</head>
***************
*** 735,743 ****
<p> [Reason] the string: "A header representing a Message Addressing Property is not valid
and the message cannot be processed" </p>
! <p> [Details] either a <wsa:ProblemHeader> element that conveys a copy of the
! offending header or a
! <wsa:ProblemHeaderQName> element that conveys the QName of the root element of the
! offending header.</p>
! <p>The invalid addressing header fault can be further narrowed in scope by use of the
additional [Subsubcode]s specified in the following subsections. Use of these
[Subsubcode] values is OPTIONAL.</p>
--- 733,740 ----
<p> [Reason] the string: "A header representing a Message Addressing Property is not valid
and the message cannot be processed" </p>
! <p> [Details] either a <wsa:ProblemHeader> element that conveys a copy of
! the offending header or a <wsa:ProblemHeaderQName> element that conveys
! the QName of the root element of the offending header.</p>
! <p>The invalid addressing header fault can be further narrowed in scope by use of the
additional [Subsubcode]s specified in the following subsections. Use of these
[Subsubcode] values is OPTIONAL.</p>
***************
*** 762,775 ****
<head>wsa:DuplicateMessageID</head>
<p>Specifies that the invalid header conveyed a [message id] that was a duplicate of one
! already received.</p>
</div4>
<div4>
<head>wsa:ActionMismatch</head>
<p>Specifies that the [action] and SOAPAction for the message did not match, [Details]
! MAY contain a <wsa:ProblemAction>
! element in addition to the <wsa:ProblemHeader> element or
! <wsa:ProblemHeaderQName> element.</p>
</div4>
-
</div3>
<div3 id="missingmapfault">
--- 759,771 ----
<head>wsa:DuplicateMessageID</head>
<p>Specifies that the invalid header conveyed a [message id] that was a duplicate of one
! already received.</p>
</div4>
<div4>
<head>wsa:ActionMismatch</head>
<p>Specifies that the [action] and SOAPAction for the message did not match, [Details]
! MAY contain a <wsa:ProblemAction> element in addition to the
! <wsa:ProblemHeader> element or <wsa:ProblemHeaderQName>
! element.</p>
</div4>
</div3>
<div3 id="missingmapfault">
***************
*** 780,785 ****
<p> [Reason] the string: "A required header representing a Message Addressing Property is
not present"</p>
! <p> [Details] a <wsa:ProblemHeaderQName> element that conveys the QName of the
! message addressing header that was missing.</p>
</div3>
<div3 id="destinationfault">
--- 776,781 ----
<p> [Reason] the string: "A required header representing a Message Addressing Property is
not present"</p>
! <p> [Details] a <wsa:ProblemHeaderQName> element that conveys the QName of
! the message addressing header that was missing.</p>
</div3>
<div3 id="destinationfault">
***************
*** 789,794 ****
<p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
<p> [Reason] the string: "No route can be determined to reach [destination]"</p>
! <p> [Details] an optional <wsa:ProblemIRI> element that conveys the [address] of the
! [destination].</p>
</div3>
<div3 id="actionfault">
--- 785,790 ----
<p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
<p> [Reason] the string: "No route can be determined to reach [destination]"</p>
! <p> [Details] an optional <wsa:ProblemIRI> element that conveys the
! [address] of the [destination].</p>
</div3>
<div3 id="actionfault">
***************
*** 798,803 ****
<p> [Subcode] a QName representing the value wsa:ActionNotSupported</p>
<p> [Reason] the string: "The [action] cannot be processed at the receiver"</p>
! <p> [Details] a <wsa:ProblemAction> element with a REQUIRED <wsa:Action> child
! element</p>
</div3>
<div3 id="unavailablefault">
--- 794,799 ----
<p> [Subcode] a QName representing the value wsa:ActionNotSupported</p>
<p> [Reason] the string: "The [action] cannot be processed at the receiver"</p>
! <p> [Details] a <wsa:ProblemAction> element with a REQUIRED
! <wsa:Action> child element</p>
</div3>
<div3 id="unavailablefault">
***************
*** 810,916 ****
<p> [Subcode] a QName representing the value wsa:EndpointUnavailable</p>
<p> [Reason] the string "The endpoint is unable to process the message at this time"</p>
! <p> [Details] an optional <wsa:RetryAfter> element and an optional <wsa:ProblemIRI> element that conveys the [address] of the
! [destination].</p>
</div3>
</div2>
-
</div1>
<div1 id="securityconsiderations">
<head>Security Considerations</head>
!
! <note><p>No assumptions are made herein of the application level security
! requirement, the organization of the application, implementation of senders
! or receivers, or of the ways that other protocols may make use of
! WS-Addressing, and what security mechanisms they may employ. A holistic
! approach to security which considers all components of the application,
! other protocols utilized, the way that these protocols compose with
! WS-Security, and the use of other methods or additional techniques is highly
! recommended.</p></note>
!
! <p>As discussed in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>],
! WS-Addressing supports capabilities that allow a message sender to
! instruct a message receiver to send additional unsolicited messages to
! other receivers of their choice and to control the contents of those
! messages to an extent using reference parameters. The SOAP binding of
! WS-Addressing transforms EPR reference parameters into SOAP headers and
! this allows a message sender to request a message receiver to send
! additional unsolicited SOAP messages to other receivers of their choice
! and to specify a set of SOAP headers that must be included in such
! messages.</p>
!
! <p>SOAP headers are a powerful extension mechanism and therefore great care
! should be taken before honoring a [reply endpoint] or [fault endpoint]
! to avoid inadvertent participation in the activities of malicious SOAP
! message senders.</p>
!
! <p>WS-Addressing message addressing properties serialized as SOAP headers
! (wsa:To, wsa:Action et al.) including those headers present as a result
! of the [reference parameters] property should be integrity protected as
! explained in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>].</p>
!
! <p>Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is
! not the predefined anonymous URI should include claims that allow a
! receiver to confirm that the EPR was issued by a principle with
! authority to represent the [address] of the EPR.</p>
!
! <p>When receiving a SOAP message, certain SOAP headers may have resulted
! from the serialization of an EPR's [reference parameters] property. A
! SOAP message receiver should perform additional security and sanity
! checks to prevent unintended actions.</p>
!
<div2>
<head>Establishing EPR Trust</head>
!
! <p>There are many mechanisms that could be used to supply proof that a
! message sender has authority to represent the [address] of EPRs supplied
! within the message. Typically such mechanisms require the inclusion of a
! WS-Security[<bibref ref="WS-Security"/>] header that contains XML digital signatures
! binding the wsa:ReplyTo and wsa:FaultTo elements to the SOAP message
! using a security token issued by an authority trusted by the receiver of
! the message for the domain of the [address] of the EPR. Possession of a
! security token issued by a trusted authority for the domain of the
! [address] of the EPR provides a level of confidence that the message
! sender has authority to represent the [address].</p>
!
<p>For example, a message could include a WS-Security[<bibref ref="WS-Security"/>] header
! that contains XML digital signatures binding the wsa:ReplyTo and
! wsa:FaultTo elements to the SOAP message using an X.509 certificate for
! the domain addressed by the [address] of the EPR. If the certificate is
! issued by a certificate authority trusted by the receiver of the message
! then the receiver can can have some level of confidence that the message
sender has authority to represent the [address] of the EPR.</p>
-
</div2>
-
<div2>
<head>Additional Security Considerations</head>
!
! <p>The wsa:isReferenceParameter attribute is only meaningful on SOAP
! headers. Message processors should consider its appearance elsewhere in
! a SOAP message as a possible attack.</p>
!
! <p>Message processors should consider elements from the soap11, soap12 and
! wsa namespaces appearing as reference parameters in an EPR as a possible
attack.</p>
!
! <p>There are known XML ID and re-structuring attacks which should be
! considered by message processors, see [<bibref ref="WS-Security"/>] - Security
! Conciderations: Removal and modification of XML elements.</p>
</div2>
-
<div2>
<head>Additional Considerations for SOAP Intermediaries</head>
!
! <p>To avoid breaking signatures, intermediaries MUST NOT change the XML
! representation of WS-Addressing headers when relaying those headers.
! Specifically, intermediaries MUST NOT remove XML content that explicitly
! indicates otherwise-implied content, and intermediaries MUST NOT insert
! XML content to make implied values explicit. For instance, if a
! RelationshipType attribute is present with a value of
! <attval>&nsuri;/reply</attval>, an intermediary MUST NOT
! remove it; similarly, if there is no RelationshipType attribute, an
! intermediary MUST NOT add one.</p>
</div2>
-
</div1>
<div1 id="conformance">
--- 806,883 ----
<p> [Subcode] a QName representing the value wsa:EndpointUnavailable</p>
<p> [Reason] the string "The endpoint is unable to process the message at this time"</p>
! <p> [Details] an optional <wsa:RetryAfter> element and an optional
! <wsa:ProblemIRI> element that conveys the [address] of the
! [destination].</p>
</div3>
</div2>
</div1>
<div1 id="securityconsiderations">
<head>Security Considerations</head>
! <note>
! <p>No assumptions are made herein of the application level security requirement, the
! organization of the application, implementation of senders or receivers, or of the ways
! that other protocols may make use of WS-Addressing, and what security mechanisms they may
! employ. A holistic approach to security which considers all components of the application,
! other protocols utilized, the way that these protocols compose with WS-Security, and the
! use of other methods or additional techniques is highly recommended.</p>
! </note>
! <p>As discussed in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>], WS-Addressing supports
! capabilities that allow a message sender to instruct a message receiver to send additional
! unsolicited messages to other receivers of their choice and to control the contents of those
! messages to an extent using reference parameters. The SOAP binding of WS-Addressing
! transforms EPR reference parameters into SOAP headers and this allows a message sender to
! request a message receiver to send additional unsolicited SOAP messages to other receivers
! of their choice and to specify a set of SOAP headers that must be included in such messages.</p>
! <p>SOAP headers are a powerful extension mechanism and therefore great care should be taken
! before honoring a [reply endpoint] or [fault endpoint] to avoid inadvertent participation in
! the activities of malicious SOAP message senders.</p>
! <p>WS-Addressing message addressing properties serialized as SOAP headers (wsa:To, wsa:Action
! et al.) including those headers present as a result of the [reference parameters] property
! should be integrity protected as explained in &wsa-core.title;[<bibref ref="WSADDR-CORE"
! />].</p>
! <p>Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is not the predefined
! anonymous URI should include claims that allow a receiver to confirm that the EPR was issued
! by a principle with authority to represent the [address] of the EPR.</p>
! <p>When receiving a SOAP message, certain SOAP headers may have resulted from the
! serialization of an EPR's [reference parameters] property. A SOAP message receiver should
! perform additional security and sanity checks to prevent unintended actions.</p>
<div2>
<head>Establishing EPR Trust</head>
! <p>There are many mechanisms that could be used to supply proof that a message sender has
! authority to represent the [address] of EPRs supplied within the message. Typically such
! mechanisms require the inclusion of a WS-Security[<bibref ref="WS-Security"/>] header that
! contains XML digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements to the
! SOAP message using a security token issued by an authority trusted by the receiver of the
! message for the domain of the [address] of the EPR. Possession of a security token issued
! by a trusted authority for the domain of the [address] of the EPR provides a level of
! confidence that the message sender has authority to represent the [address].</p>
<p>For example, a message could include a WS-Security[<bibref ref="WS-Security"/>] header
! that contains XML digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements to
! the SOAP message using an X.509 certificate for the domain addressed by the [address] of
! the EPR. If the certificate is issued by a certificate authority trusted by the receiver
! of the message then the receiver can can have some level of confidence that the message
sender has authority to represent the [address] of the EPR.</p>
</div2>
<div2>
<head>Additional Security Considerations</head>
! <p>The wsa:isReferenceParameter attribute is only meaningful on SOAP headers. Message
! processors should consider its appearance elsewhere in a SOAP message as a possible
attack.</p>
! <p>Message processors should consider elements from the soap11, soap12 and wsa namespaces
! appearing as reference parameters in an EPR as a possible attack.</p>
! <p>There are known XML ID and re-structuring attacks which should be considered by message
! processors, see [<bibref ref="WS-Security"/>] - Security Conciderations: Removal and
! modification of XML elements.</p>
</div2>
<div2>
<head>Additional Considerations for SOAP Intermediaries</head>
! <p>To avoid breaking signatures, intermediaries MUST NOT change the XML representation of
! WS-Addressing headers when relaying those headers. Specifically, intermediaries MUST NOT
! remove XML content that explicitly indicates otherwise-implied content, and intermediaries
! MUST NOT insert XML content to make implied values explicit. For instance, if a
! RelationshipType attribute is present with a value of <attval>&nsuri;/reply</attval>,
! an intermediary MUST NOT remove it; similarly, if there is no RelationshipType attribute,
! an intermediary MUST NOT add one.</p>
</div2>
</div1>
<div1 id="conformance">
***************
*** 935,941 ****
<p>Endpoints MAY accept and respond to messages which contain no WSA headers.</p>
</note>
! <p>If a receiver processes a message containing a wsa:Action header,
! this SOAP binding is engaged, and the rules of this specification are in force.</p>
! </div1>
<div1 id="references">
<head> References</head>
--- 902,908 ----
<p>Endpoints MAY accept and respond to messages which contain no WSA headers.</p>
</note>
! <p>If a receiver processes a message containing a wsa:Action header, this SOAP binding is
! engaged, and the rules of this specification are in force.</p>
! </div1>
<div1 id="references">
<head> References</head>
***************
*** 943,957 ****
<bibl key="WS-Addressing-Core" id="WSADDR-CORE" href="&w3c-designation-wsa-core;">
<titleref>&wsa-core.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
! <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
! href="&w3c-designation-wsa-wsdl;">
<titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
! <bibl key="WSDL 2.0" id="WSDL20" href="&w3c-designation-wsa-wsdl;">
! <titleref>Web Services Description Language (WSDL)
! Version 2.0 Part 1: Core Language</titleref>,
! R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide Web
! Consortium, 3 August 2005. This version of the WSDL 2.0 specification is
! http://www.w3.org/TR/2005/WD-wsdl20-20050803. The <loc
! href="http://www.w3.org/TR/wsdl20">latest version of WSDL 2.0</loc> is
! available at http://www.w3.org/TR/wsdl20.</bibl>
<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119">
<titleref>Key words for use in RFCs to Indicate Requirement Levels</titleref>, S. Bradner,
--- 910,921 ----
<bibl key="WS-Addressing-Core" id="WSADDR-CORE" href="&w3c-designation-wsa-core;">
<titleref>&wsa-core.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
! <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL" href="&w3c-designation-wsa-wsdl;">
<titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
! <bibl key="WSDL 2.0" id="WSDL20" href="&w3c-designation-wsa-wsdl;">
! <titleref>Web Services Description Language (WSDL) Version 2.0 Part 1: Core
! Language</titleref>, R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World
! Wide Web Consortium, 3 August 2005. This version of the WSDL 2.0 specification is
! http://www.w3.org/TR/2005/WD-wsdl20-20050803. The <loc href="http://www.w3.org/TR/wsdl20"
! >latest version of WSDL 2.0</loc> is available at http://www.w3.org/TR/wsdl20.</bibl>
<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119">
<titleref>Key words for use in RFCs to Indicate Requirement Levels</titleref>, S. Bradner,
***************
*** 1015,1019 ****
Box, et al, <titleref>Simple Object Access Protocol (SOAP) 1.1</titleref>, May 2000.</bibl>
<bibl id="WS-Security" key="WS-Security"
! href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"> OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>, March
2004.</bibl>
</blist>
--- 979,984 ----
Box, et al, <titleref>Simple Object Access Protocol (SOAP) 1.1</titleref>, May 2000.</bibl>
<bibl id="WS-Security" key="WS-Security"
! href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"
! > OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>, March
2004.</bibl>
</blist>
Received on Tuesday, 22 November 2005 20:41:46 UTC