- 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
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><wse:NotifyTo></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><s12:Body></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 @@
6.10 <a href="#UnknownSubscription">UnknownSubscription</a><br/>
6.11 <a href="#EndToNotSupported">EndToNotSupported</a><br/>
7 <a href="#Security">Security Considerations</a><br/>
- 7.1 <a href="#MessageSecurity">Message Security</a><br/>
- 7.2 <a href="#AccessControl">Access Control</a><br/>
+ 7.1 <a href="#iddiv2_1_2102">Notifications</a><br/>
+ 7.2 <a href="#iddiv2_1_2111">Subscriptions</a><br/>
+ 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/>
- 9.1 <a href="#iddiv2_1_2190">EventSource Assertion</a><br/>
- 9.2 <a href="#iddiv2_1_2293">SubscriptionManager Assertion</a><br/>
+ 9.1 <a href="#iddiv2_1_2142">EventSource Assertion</a><br/>
+ 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/>
- 11.1 <a href="#iddiv2_1_2367">Normative References</a><br/>
- 11.2 <a href="#iddiv2_1_2514">Informative References</a><br/>
+ 11.1 <a href="#iddiv2_1_2319">Normative References</a><br/>
+ 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/>
A.1 <a href="#ETypes">Event Types & Event Descriptions</a><br/>
- A.1.1 <a href="#iddiv3_1_2703">Retrieving Event Descriptions</a><br/>
- A.1.2 <a href="#iddiv3_1_2740">Bindings for Event Descriptions</a><br/>
- A.1.2.1 <a href="#iddiv4_1_2745">Binding for Unwrapped Notifications</a><br/>
- A.1.2.2 <a href="#iddiv4_1_2766">Binding for Wrapped Notifications</a><br/>
+ A.1.1 <a href="#iddiv3_1_2655">Retrieving Event Descriptions</a><br/>
+ A.1.2 <a href="#iddiv3_1_2692">Bindings for Event Descriptions</a><br/>
+ A.1.2.1 <a href="#iddiv4_1_2697">Binding for Unwrapped Notifications</a><br/>
+ A.1.2.2 <a href="#iddiv4_1_2718">Binding for Wrapped Notifications</a><br/>
A.2 <a href="#NWSDL">Notification WSDLs</a><br/>
- A.2.1 <a href="#iddiv3_1_2793">Retrieving Notification WSDLs</a><br/>
+ 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><wse:NotifyTo></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><s12:Body></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) <wsevd:EventDescriptions
+<div class="exampleHeader"><a name="idexample_1_2645" id="idexample_1_2645"/>Example A-1: EventDescriptions</div><div class="exampleInner"><pre>(01) <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">
@@ -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) <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) <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) </wsdl:operation>
(34) </wsdl:binding>
(35) </wsdl:definitions></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 UTC