W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > May 2010

WWW/2002/ws/ra/edcopies wseventing.html,1.185,1.186 wseventing.xml,1.178,1.179

From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 11 May 2010 19:03:24 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1OBujk-0003ag-EB@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv13530

Modified Files:
	wseventing.html wseventing.xml 
Log Message:
9567


Index: wseventing.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.xml,v
retrieving revision 1.178
retrieving revision 1.179
diff -u -d -r1.178 -r1.179
--- wseventing.xml	5 May 2010 02:42:44 -0000	1.178
+++ wseventing.xml	11 May 2010 19:03:22 -0000	1.179
@@ -2518,163 +2518,103 @@
   <div1 id="Security">
    <head>Security Considerations</head>
 
-   <div2 id="MessageSecurity">
-    <head>Message Security</head>
+   <p>
+    This specification considers two sets of security requirements, those of 
+    the applications that use the WS-Eventing protocol and those of the 
+    protocol itself.
+   </p>
 
-    <p>
-     It is strongly RECOMMENDED that the communication between
-     services be secured using the mechanisms described in WS-Security
-     <bibref ref="WSSecurity"/>. In order to properly
-     secure messages, the body and all relevant headers need to be
-     included in the signature. Specifically, any headers identified
-     in the <code>&lt;wse:NotifyTo&gt;</code> element and standard
-     messaging headers, such as those from WS-Addressing 
-     <bibref ref="AddrCore"/>, need to be signed with the
-     body in order to "bind" the two together. For messages with empty
-     bodies, the <code>&lt;s12:Body&gt;</code> element SHOULD be
-     signed so content cannot be added in transit.
-    </p>
+   <p>
+    This specification makes no assumptions about the security requirements 
+    of the applications that use WS-Eventing. However, once those 
+    requirements have been satisfied within a given operational context, 
+    the addition of WS-Eventing to this operational context cannot 
+    undermine the fulfillment of those requirements; the use of 
+    WS-Eventing SHOULD NOT create additional attack vectors within an 
+    otherwise secure system.
+   </p>
+
+   <p>
+    The material below is not a "check list". There are many other 
+    security concerns that need to be considered when implementing or 
+    using this protocol. Implementers and users of this protocol are 
+    urged to perform a security analysis to determine their particular 
+    threat profile and the appropriate responses to those threats.
+   </p>
+
+   <div2>
+    <head>Notifications</head>
 
     <p>
-     Different security mechanisms might be desired depending on the
-     frequency of messages. For example, for infrequent messages,
-     public key technologies might be adequate for integrity and
-     confidentiality. However, for high-frequency events, it could be
-     more performant to establish a security context for the events
-     using the mechanisms described in WS-Trust 
-     <bibref ref="WSTrust"/> and WS-SecureConversation 
-     <bibref ref="WSSecureConversation"/>.
+     The information contained in Notifications might be sensitive. In 
+     such cases it is advisable to authenticate and authorize subscribers 
+     as part of the processing of the Subscribe request. Note that an 
+     Event Source may authorize the delivery of Notifications on a 
+     per-message basis after the subscription has been created. This 
+     might be necessary in cases where the sensitivity of the Notification 
+     information is not known at Subscribe time or varies over the 
+     lifetime of a subscription.
     </p>
 
     <p>
-     Note that if a shared secret is used it is
-     RECOMMENDED that derived keys be used to strengthen the secret as
-     described in WS-SecureConversation.
+     To protect the Notifications sent over a network, Notifications ought 
+     to have the proper authenticity, integrity and confidentiality 
+     protections applied.
     </p>
 
     <p>
-     The following list summarizes common classes of attacks that
-     apply to this protocol and identifies the mechanism to
-     prevent/mitigate the attacks:
+     The ability to subscribe on behalf of a third-party Event Sink 
+     could be misused by a malicious Subscriber to create a 
+     denial-of-service attack. While it does not remove the ability for 
+     such misuse, authenticating Subscribers provides a way to deter 
+     and trace the origin of such attempts. Additionally, the 
+     authorization of Subscribers reduces the pool of potential attackers.
     </p>
-
-    <ulist>
-     <item>
-      <p>
-        Message alteration  - Alteration is
-       prevented by including signatures of the message information
-       using WS-Security.
-      </p>
-     </item>
-
-     <item>
-      <p>
-        Message disclosure  -
-       Confidentiality is preserved by encrypting sensitive data
-       using WS-Security.
-      </p>
-     </item>
-
-     <item>
-      <p>
-        Key integrity  - Key integrity is
-       maintained by using the strongest algorithms possible (by
-       comparing secured policies - see WS-Policy 
-       <bibref ref="wspolicy"/> and WS-SecurityPolicy 
-       <bibref ref="WSSecurityPolicy"/>).
-      </p>
-     </item>
-
-     <item>
-      <p>
-        Authentication  - Authentication is
-       established using the mechanisms described in WS-Security and
-       WS-Trust. Each message is authenticated using the mechanisms
-       described in WS-Security.
-      </p>
-     </item>
-
-     <item>
-      <p>
-        Accountability  - Accountability is
-       a function of the type of and string of the key and
-       algorithms being used. In many cases, a strong symmetric key
-       provides sufficient accountability. However, in some
-       environments, strong PKI signatures are needed.
-      </p>
-     </item>
-
-     <item>
-      <p>
-        Availability  - All reliable
-       messaging services are subject to a variety of availability
-       attacks. Replay detection is a common attack and it is
-       RECOMMENDED that this be addressed by the mechanisms
-       described in WS-Security. Other attacks, such as
-       network-level denial of service attacks are harder to avoid
-       and are outside the scope of this specification. That said,
-       care SHOULD be taken to ensure that minimal state is saved
-       prior to any authenticating sequences.
-      </p>
-     </item>
-
-     <item>
-      <p>
-        Replay  - Messages might be replayed
-       for a variety of reasons. To detect and eliminate this
-       attack, mechanisms SHOULD be used to identify replayed
-       messages such as the timestamp/nonce outlined in WS-Security.
-       Alternatively, and OPTIONALLY, other technologies, such as
-       sequencing, can also be used to prevent replay of application
-       messages.
-      </p>
-     </item>
-    </ulist>
    </div2>
 
-   <div2 id="AccessControl">
-    <head>Access Control</head>
+   <div2>
+    <head>Subscriptions</head>
 
     <p>
-     It is important for event sources and subscription managers
-     to properly authorize
-     requests. This is especially true for Subscribe requests, as
-     otherwise the ability to subscribe on behalf of a third-party
-     event sink could be used to create a distributed
-     denial-of-service attack.
+     Once created, subscriptions ought to be treated as protected 
+     resources. Renew, GetStatus, and Unsubscribe requests ought to be 
+     authenticated and authorized (for example, the identity of the 
+     requester ought to be checked against the identity of the entity 
+     that performed the original Subscribe request). Likewise 
+     SubscriptionEnd messages ought to be authenticated and authorized 
+     (for example, the identity of the sender ought to be checked 
+     against the identity of the entity that sent the original 
+     SubscribeResponse message). Note that authentication and 
+     authorization policies (i.e. the rules that define which entities 
+     are allowed to perform which requests and the mechanisms by which 
+     the identities of these entities are discovered and verified) 
+     are particular to individual deployments.
     </p>
+   </div2>
+
+   <div2>
+    <head>Endpoint Verification</head>
 
     <p>
-     Some possible schemes for validating Subscribe requests
-     include:
+     Implementations that perform validity checks on the EPRs used in 
+     WS-Eventing (wse:NotifyTo, wse:EndTo) are advised that such checks 
+     can be misused to obtain information about a target network. For 
+     example, suppose an Event Source implementation verifies the address 
+     of NotifyTo EPRs by attempting to create a connection to the EPR's
+     address and faulting the Subscribe request if a connection cannot 
+     be created. When deployed within a DMZ, such an Event Source could 
+     be exploited by a malicious Subscriber to probe for other, 
+     non-visible hosts by guessing target addresses and using them in 
+     Subscribe requests. Note that, even if the returned fault does not 
+     provide connection information, the time the Event Source spends 
+     processing the Subscribe request might reveal if there is a host 
+     with the target address.
     </p>
 
-    <ulist>
-     <item>
-      <p>
-       Send a message to the event sink that describes the
-       requested subscription, and then wait for a confirmation
-       message to be returned by the event sink, before the event
-       source accepts the subscription request. While this provides
-       strong assurance that the event sink actually desires the
-       requested subscription, it does not work for event sinks that
-       are not capable of sending a confirmation, and requires
-       additional logic on the event sink.
-      </p>
-     </item>
-
-     <item>
-      <p>
-       Require user authentication on the Subscribe request, and
-       allow only authorized users to Subscribe.
-      </p>
-     </item>
-    </ulist>
-
     <p>
-     Other mechanisms are also possible. Note that event sources
-     that are not reachable from the Internet have less need to
-     control Subscribe requests.
+     Implementations that perform validity checks on the EPRs used in 
+     WS-Eventing are advised to provide a means to disable such checks 
+     in environments where these types of attacks are an issue.
     </p>
    </div2>
 
@@ -5053,10 +4993,10 @@
       </td>
      </tr>
      <tr>
-      <td> 2010/05/04 </td>
+      <td> 2010/05/11 </td>
       <td> DD </td>
       <td> Added resolution of issue
-       <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9087">9087</loc>
+       <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9567">9567</loc>
       </td>
      </tr>
     </tbody>

Index: wseventing.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.html,v
retrieving revision 1.185
retrieving revision 1.186
diff -u -d -r1.185 -r1.186
--- wseventing.html	5 May 2010 02:42:44 -0000	1.185
+++ wseventing.html	11 May 2010 19:03:22 -0000	1.186
@@ -72,25 +72,26 @@
 &nbsp;&nbsp;&nbsp;6.10 <a href="#UnknownSubscription">UnknownSubscription</a><br/>
 &nbsp;&nbsp;&nbsp;6.11 <a href="#EndToNotSupported">EndToNotSupported</a><br/>
 7 <a href="#Security">Security Considerations</a><br/>
-&nbsp;&nbsp;&nbsp;7.1 <a href="#MessageSecurity">Message Security</a><br/>
-&nbsp;&nbsp;&nbsp;7.2 <a href="#AccessControl">Access Control</a><br/>
+&nbsp;&nbsp;&nbsp;7.1 <a href="#iddiv2_1_2102">Notifications</a><br/>
+&nbsp;&nbsp;&nbsp;7.2 <a href="#iddiv2_1_2111">Subscriptions</a><br/>
+&nbsp;&nbsp;&nbsp;7.3 <a href="#iddiv2_1_2116">Endpoint Verification</a><br/>
 8 <a href="#ImplConsideration">Implementation Considerations</a><br/>
 9 <a href="#metadata">WS-Eventing Metadata</a><br/>
-&nbsp;&nbsp;&nbsp;9.1 <a href="#iddiv2_1_2190">EventSource Assertion</a><br/>
-&nbsp;&nbsp;&nbsp;9.2 <a href="#iddiv2_1_2293">SubscriptionManager Assertion</a><br/>
+&nbsp;&nbsp;&nbsp;9.1 <a href="#iddiv2_1_2142">EventSource Assertion</a><br/>
+&nbsp;&nbsp;&nbsp;9.2 <a href="#iddiv2_1_2245">SubscriptionManager Assertion</a><br/>
 10 <a href="#acks">Acknowledgements</a><br/>
 11 <a href="#refs">References</a><br/>
-&nbsp;&nbsp;&nbsp;11.1 <a href="#iddiv2_1_2367">Normative References</a><br/>
-&nbsp;&nbsp;&nbsp;11.2 <a href="#iddiv2_1_2514">Informative References</a><br/>
+&nbsp;&nbsp;&nbsp;11.1 <a href="#iddiv2_1_2319">Normative References</a><br/>
+&nbsp;&nbsp;&nbsp;11.2 <a href="#iddiv2_1_2466">Informative References</a><br/>
 </p>
 <h3><a name="appendices" id="appendices"/>Appendices</h3><p class="toc">A <a href="#Advertising">Advertising Event Information</a><br/>
 &nbsp;&nbsp;&nbsp;A.1 <a href="#ETypes">Event Types &amp; Event Descriptions</a><br/>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.1 <a href="#iddiv3_1_2703">Retrieving Event Descriptions</a><br/>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.2 <a href="#iddiv3_1_2740">Bindings for Event Descriptions</a><br/>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.2.1 <a href="#iddiv4_1_2745">Binding for Unwrapped Notifications</a><br/>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.2.2 <a href="#iddiv4_1_2766">Binding for Wrapped Notifications</a><br/>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.1 <a href="#iddiv3_1_2655">Retrieving Event Descriptions</a><br/>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.2 <a href="#iddiv3_1_2692">Bindings for Event Descriptions</a><br/>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.2.1 <a href="#iddiv4_1_2697">Binding for Unwrapped Notifications</a><br/>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.1.2.2 <a href="#iddiv4_1_2718">Binding for Wrapped Notifications</a><br/>
 &nbsp;&nbsp;&nbsp;A.2 <a href="#NWSDL">Notification WSDLs</a><br/>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.2.1 <a href="#iddiv3_1_2793">Retrieving Notification WSDLs</a><br/>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A.2.1 <a href="#iddiv3_1_2745">Retrieving Notification WSDLs</a><br/>
 B <a href="#Schema">XML Schema</a><br/>
 C <a href="#WSDL">WSDL</a><br/>
 D <a href="#wrappedWSDL">WSDL for Standard Wrapped Delivery</a><br/>
@@ -1402,106 +1403,79 @@
      /wse:Subscribe/wse:EndTo semantics, in response to a subscription 
      request that contains a wse:EndTo element. 
     </p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:EndToNotSupported</td></tr><tr><td><b>[Reason]</b></td><td>wse:EndTo semantics is not supported.</td></tr><tr><td><b>[Detail]</b></td><td><em>none</em></td></tr></tbody></table></div></div><div class="div1">
-<h2><a name="Security" id="Security"/>7 Security Considerations</h2><div class="div2">
-<h3><a name="MessageSecurity" id="MessageSecurity"/>7.1 Message Security</h3><p>
-     It is strongly RECOMMENDED that the communication between
-     services be secured using the mechanisms described in WS-Security
-     <a href="#WSSecurity">[WS-Security]</a>. In order to properly
-     secure messages, the body and all relevant headers need to be
-     included in the signature. Specifically, any headers identified
-     in the <code>&lt;wse:NotifyTo&gt;</code> element and standard
-     messaging headers, such as those from WS-Addressing 
-     <a href="#AddrCore">[WS-Addressing]</a>, need to be signed with the
-     body in order to "bind" the two together. For messages with empty
-     bodies, the <code>&lt;s12:Body&gt;</code> element SHOULD be
-     signed so content cannot be added in transit.
-    </p><p>
-     Different security mechanisms might be desired depending on the
-     frequency of messages. For example, for infrequent messages,
-     public key technologies might be adequate for integrity and
-     confidentiality. However, for high-frequency events, it could be
-     more performant to establish a security context for the events
-     using the mechanisms described in WS-Trust 
-     <a href="#WSTrust">[WS-Trust]</a> and WS-SecureConversation 
-     <a href="#WSSecureConversation">[WS-SecureConversation]</a>.
+<h2><a name="Security" id="Security"/>7 Security Considerations</h2><p>
+    This specification considers two sets of security requirements, those of 
+    the applications that use the WS-Eventing protocol and those of the 
+    protocol itself.
+   </p><p>
+    This specification makes no assumptions about the security requirements 
+    of the applications that use WS-Eventing. However, once those 
+    requirements have been satisfied within a given operational context, 
+    the addition of WS-Eventing to this operational context cannot 
+    undermine the fulfillment of those requirements; the use of 
+    WS-Eventing SHOULD NOT create additional attack vectors within an 
+    otherwise secure system.
+   </p><p>
+    The material below is not a "check list". There are many other 
+    security concerns that need to be considered when implementing or 
+    using this protocol. Implementers and users of this protocol are 
+    urged to perform a security analysis to determine their particular 
+    threat profile and the appropriate responses to those threats.
+   </p><div class="div2">
+<h3><a name="iddiv2_1_2102" id="iddiv2_1_2102"/>7.1 Notifications</h3><p>
+     The information contained in Notifications might be sensitive. In 
+     such cases it is advisable to authenticate and authorize subscribers 
+     as part of the processing of the Subscribe request. Note that an 
+     Event Source may authorize the delivery of Notifications on a 
+     per-message basis after the subscription has been created. This 
+     might be necessary in cases where the sensitivity of the Notification 
+     information is not known at Subscribe time or varies over the 
+     lifetime of a subscription.
     </p><p>
-     Note that if a shared secret is used it is
-     RECOMMENDED that derived keys be used to strengthen the secret as
-     described in WS-SecureConversation.
+     To protect the Notifications sent over a network, Notifications ought 
+     to have the proper authenticity, integrity and confidentiality 
+     protections applied.
     </p><p>
-     The following list summarizes common classes of attacks that
-     apply to this protocol and identifies the mechanism to
-     prevent/mitigate the attacks:
-    </p><ul><li><p>
-        Message alteration  - Alteration is
-       prevented by including signatures of the message information
-       using WS-Security.
-      </p></li><li><p>
-        Message disclosure  -
-       Confidentiality is preserved by encrypting sensitive data
-       using WS-Security.
-      </p></li><li><p>
-        Key integrity  - Key integrity is
-       maintained by using the strongest algorithms possible (by
-       comparing secured policies - see WS-Policy 
-       <a href="#wspolicy">[WS-Policy]</a> and WS-SecurityPolicy 
-       <a href="#WSSecurityPolicy">[WS-SecurityPolicy]</a>).
-      </p></li><li><p>
-        Authentication  - Authentication is
-       established using the mechanisms described in WS-Security and
-       WS-Trust. Each message is authenticated using the mechanisms
-       described in WS-Security.
-      </p></li><li><p>
-        Accountability  - Accountability is
-       a function of the type of and string of the key and
-       algorithms being used. In many cases, a strong symmetric key
-       provides sufficient accountability. However, in some
-       environments, strong PKI signatures are needed.
-      </p></li><li><p>
-        Availability  - All reliable
-       messaging services are subject to a variety of availability
-       attacks. Replay detection is a common attack and it is
-       RECOMMENDED that this be addressed by the mechanisms
-       described in WS-Security. Other attacks, such as
-       network-level denial of service attacks are harder to avoid
-       and are outside the scope of this specification. That said,
-       care SHOULD be taken to ensure that minimal state is saved
-       prior to any authenticating sequences.
-      </p></li><li><p>
-        Replay  - Messages might be replayed
-       for a variety of reasons. To detect and eliminate this
-       attack, mechanisms SHOULD be used to identify replayed
-       messages such as the timestamp/nonce outlined in WS-Security.
-       Alternatively, and OPTIONALLY, other technologies, such as
-       sequencing, can also be used to prevent replay of application
-       messages.
-      </p></li></ul></div><div class="div2">
-<h3><a name="AccessControl" id="AccessControl"/>7.2 Access Control</h3><p>
-     It is important for event sources and subscription managers
-     to properly authorize
-     requests. This is especially true for Subscribe requests, as
-     otherwise the ability to subscribe on behalf of a third-party
-     event sink could be used to create a distributed
-     denial-of-service attack.
+     The ability to subscribe on behalf of a third-party Event Sink 
+     could be misused by a malicious Subscriber to create a 
+     denial-of-service attack. While it does not remove the ability for 
+     such misuse, authenticating Subscribers provides a way to deter 
+     and trace the origin of such attempts. Additionally, the 
+     authorization of Subscribers reduces the pool of potential attackers.
+    </p></div><div class="div2">
+<h3><a name="iddiv2_1_2111" id="iddiv2_1_2111"/>7.2 Subscriptions</h3><p>
+     Once created, subscriptions ought to be treated as protected 
+     resources. Renew, GetStatus, and Unsubscribe requests ought to be 
+     authenticated and authorized (for example, the identity of the 
+     requester ought to be checked against the identity of the entity 
+     that performed the original Subscribe request). Likewise 
+     SubscriptionEnd messages ought to be authenticated and authorized 
+     (for example, the identity of the sender ought to be checked 
+     against the identity of the entity that sent the original 
+     SubscribeResponse message). Note that authentication and 
+     authorization policies (i.e. the rules that define which entities 
+     are allowed to perform which requests and the mechanisms by which 
+     the identities of these entities are discovered and verified) 
+     are particular to individual deployments.
+    </p></div><div class="div2">
+<h3><a name="iddiv2_1_2116" id="iddiv2_1_2116"/>7.3 Endpoint Verification</h3><p>
+     Implementations that perform validity checks on the EPRs used in 
+     WS-Eventing (wse:NotifyTo, wse:EndTo) are advised that such checks 
+     can be misused to obtain information about a target network. For 
+     example, suppose an Event Source implementation verifies the address 
+     of NotifyTo EPRs by attempting to create a connection to the EPR's
+     address and faulting the Subscribe request if a connection cannot 
+     be created. When deployed within a DMZ, such an Event Source could 
+     be exploited by a malicious Subscriber to probe for other, 
+     non-visible hosts by guessing target addresses and using them in 
+     Subscribe requests. Note that, even if the returned fault does not 
+     provide connection information, the time the Event Source spends 
+     processing the Subscribe request might reveal if there is a host 
+     with the target address.
     </p><p>
-     Some possible schemes for validating Subscribe requests
-     include:
-    </p><ul><li><p>
-       Send a message to the event sink that describes the
-       requested subscription, and then wait for a confirmation
-       message to be returned by the event sink, before the event
-       source accepts the subscription request. While this provides
-       strong assurance that the event sink actually desires the
-       requested subscription, it does not work for event sinks that
-       are not capable of sending a confirmation, and requires
-       additional logic on the event sink.
-      </p></li><li><p>
-       Require user authentication on the Subscribe request, and
-       allow only authorized users to Subscribe.
-      </p></li></ul><p>
-     Other mechanisms are also possible. Note that event sources
-     that are not reachable from the Internet have less need to
-     control Subscribe requests.
+     Implementations that perform validity checks on the EPRs used in 
+     WS-Eventing are advised to provide a means to disable such checks 
+     in environments where these types of attacks are an issue.
     </p></div></div><div class="div1">
 <h2><a name="ImplConsideration" id="ImplConsideration"/>8 Implementation Considerations</h2><p>
     Event sinks SHOULD be prepared to receive notifications after
@@ -1535,7 +1509,7 @@
     that indicate a particular security mechanism used to protect
     the WS-Eventing operations supported by this endpoint.
    </p><div class="div2">
-<h3><a name="iddiv2_1_2190" id="iddiv2_1_2190"/>9.1 EventSource Assertion</h3><p>
+<h3><a name="iddiv2_1_2142" id="iddiv2_1_2142"/>9.1 EventSource Assertion</h3><p>
      Services indicate support for the WS-Eventing's definition 
      of an event source through the use of the Web Services
      Policy - Framework <a href="#wspolicy">[WS-Policy]</a> and Web Services Policy -
@@ -1618,7 +1592,7 @@
      Note: The WS-RA WG is interested in Last Call feedback on the use
      of nested policy expressions.
     </p></div><div class="div2">
-<h3><a name="iddiv2_1_2293" id="iddiv2_1_2293"/>9.2 SubscriptionManager Assertion</h3><p>
+<h3><a name="iddiv2_1_2245" id="iddiv2_1_2245"/>9.2 SubscriptionManager Assertion</h3><p>
      Services indicate support for the
      WS-Eventing's definition of a subscription manager 
      through the use of the Web Services
@@ -1698,7 +1672,7 @@
      Yves Lafon (W3C/ERCIM).
    </p></div><div class="div1">
 <h2><a name="refs" id="refs"/>11 References</h2><div class="div2">
-<h3><a name="iddiv2_1_2367" id="iddiv2_1_2367"/>11.1 Normative References</h3><dl><dt class="label"><a name="RFC2119" id="RFC2119"/>RFC 2119</dt><dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>
+<h3><a name="iddiv2_1_2319" id="iddiv2_1_2319"/>11.1 Normative References</h3><dl><dt class="label"><a name="RFC2119" id="RFC2119"/>RFC 2119</dt><dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>
         Key words for use in RFCs to Indicate Requirement Levels
        </cite></a>
        , S. Bradner, Author.
@@ -1755,7 +1729,7 @@
        , E. Christensen, et al., Editors.
        World Wide Web Consortium (W3C), 15 March 2001
       Available at <a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">http://www.w3.org/TR/2001/NOTE-wsdl-20010315</a>.</dd></dl></div><div class="div2">
-<h3><a name="iddiv2_1_2514" id="iddiv2_1_2514"/>11.2 Informative References</h3><dl><dt class="label"><a name="WSMC" id="WSMC"/>WS-MakeConnection</dt><dd><a href="http://docs.oasis-open.org/ws-rx/wsmc/v1.1/wsmc.doc"><cite>
+<h3><a name="iddiv2_1_2466" id="iddiv2_1_2466"/>11.2 Informative References</h3><dl><dt class="label"><a name="WSMC" id="WSMC"/>WS-MakeConnection</dt><dd><a href="http://docs.oasis-open.org/ws-rx/wsmc/v1.1/wsmc.doc"><cite>
         OASIS Standard, "Web Services Make Connection (WS-MakeConnection) 1.1"
         Web Services Make Connection (WS-MakeConnection)
        </cite></a>
@@ -1854,7 +1828,7 @@
      serve as a description of the Event Type used in 
      <a href="#Table1">Example 2-1</a>.
     </p><div class="exampleOuter">
-<div class="exampleHeader"><a name="idexample_1_2693" id="idexample_1_2693"/>Example A-1: EventDescriptions</div><div class="exampleInner"><pre>(01) &lt;wsevd:EventDescriptions 
+<div class="exampleHeader"><a name="idexample_1_2645" id="idexample_1_2645"/>Example A-1: EventDescriptions</div><div class="exampleInner"><pre>(01) &lt;wsevd:EventDescriptions 
 (02)        targetNamespace="http://www.example.org/oceanwatch/notifications"
 (03)        xmlns:wsevd="http://www.w3.org/2002/ws/ra/edcopies/ws-evt"
 (04)        xmlns:ow="http://www.example.org/oceanwatch"&gt;
@@ -1874,7 +1848,7 @@
      GED for this Event Type is defined on line (08) as being of type 
      "{http://www.example.org/oceanwatch}:WindReportType". 
     </p><div class="div3">
-<h4><a name="iddiv3_1_2703" id="iddiv3_1_2703"/>A.1.1 Retrieving Event Descriptions</h4><p>
+<h4><a name="iddiv3_1_2655" id="iddiv3_1_2655"/>A.1.1 Retrieving Event Descriptions</h4><p>
       Although there are many ways in which an event source can make its 
       EventDescriptions available, this specification RECOMMENDS the use of 
       the mechanisms described in WS-MetadataExchange <a href="#MEX">[WS-MetadataExchange]</a>.
@@ -1912,7 +1886,7 @@
       representation is the Event Description metadata. The data can be
       retrieved via an HTTP GET to the specified URL.
      </p></div><div class="div3">
-<h4><a name="iddiv3_1_2740" id="iddiv3_1_2740"/>A.1.2 Bindings for Event Descriptions</h4><p>
+<h4><a name="iddiv3_1_2692" id="iddiv3_1_2692"/>A.1.2 Bindings for Event Descriptions</h4><p>
       For any Notification Format it MUST be possible to determine how a 
       given wsevd:eventType will appear on the wire as a notification in a 
       subscription created with that format. The following sections define 
@@ -1924,7 +1898,7 @@
       Format, implementations MAY provide a Notification WSDL (see below) 
       that explicitly describes the notification operations. 
      </p><div class="div4">
-<h5><a name="iddiv4_1_2745" id="iddiv4_1_2745"/>A.1.2.1 Binding for Unwrapped Notifications</h5><p>
+<h5><a name="iddiv4_1_2697" id="iddiv4_1_2697"/>A.1.2.1 Binding for Unwrapped Notifications</h5><p>
        The information about an Event Type contained in the wsevd:eventType 
        element binds to a Unwrapped Notification for that type as follows:
       </p><ul><li><p>
@@ -1939,7 +1913,7 @@
          event being transmitted. If the @element attribute is absent then
          the <b>[Body]</b> property has no children.
         </p></li></ul></div><div class="div4">
-<h5><a name="iddiv4_1_2766" id="iddiv4_1_2766"/>A.1.2.2 Binding for Wrapped Notifications</h5><p>
+<h5><a name="iddiv4_1_2718" id="iddiv4_1_2718"/>A.1.2.2 Binding for Wrapped Notifications</h5><p>
        The information about an Event Type contained in the eventType element 
        binds to a Wrapped Notification for that type as follows: 
       </p><ul><li><p>
@@ -1965,7 +1939,7 @@
      successful Subscribe request that used a particular Format IRI. The 
      following is an example of a Notification WSDL: 
     </p><div class="exampleOuter">
-<div class="exampleHeader"><a name="idexample_1_2787" id="idexample_1_2787"/>Example A-4: Notification WSDL</div><div class="exampleInner"><pre>(01) &lt;wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
+<div class="exampleHeader"><a name="idexample_1_2739" id="idexample_1_2739"/>Example A-4: Notification WSDL</div><div class="exampleInner"><pre>(01) &lt;wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 (02)                   targetNamespace="http://www.example.org/oceanwatch/notifications"
 (03)                   xmlns:xs="http://www.w3.org/2001/XMLSchema"
 (04)                   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
@@ -2000,7 +1974,7 @@
 (33)     &lt;/wsdl:operation&gt;
 (34)   &lt;/wsdl:binding&gt;
 (35) &lt;/wsdl:definitions&gt;</pre></div></div><div class="div3">
-<h4><a name="iddiv3_1_2793" id="iddiv3_1_2793"/>A.2.1 Retrieving Notification WSDLs</h4><p>
+<h4><a name="iddiv3_1_2745" id="iddiv3_1_2745"/>A.2.1 Retrieving Notification WSDLs</h4><p>
       Although there are many ways in which an event source can make 
       Notification WSDLs available, this specification RECOMMENDS the use of 
       the mechanisms described in WS-MetadataExchange <a href="#MEX">[WS-MetadataExchange]</a>.
@@ -2694,5 +2668,5 @@
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9321">9321</a></td></tr><tr><td> 2010/04/20 </td><td> DD </td><td> Added resolution of issue
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9543">9543</a></td></tr><tr><td> 2010/04/27 </td><td> DD </td><td> Added resolution of issue
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8832">8832</a></td></tr><tr><td> 2010/05/04 </td><td> DD </td><td> Added resolution of issue
-       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9588">9588</a></td></tr><tr><td> 2010/05/04 </td><td> DD </td><td> Added resolution of issue
-       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9087">9087</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
+       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9588">9588</a></td></tr><tr><td> 2010/05/11 </td><td> DD </td><td> Added resolution of issue
+       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=9567">9567</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 11 May 2010 19:03:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 May 2010 19:03:26 GMT