- From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 26 Aug 2009 13:14:31 +0000
- To: public-ws-resource-access-notifications@w3.org
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv10227
Modified Files:
wseventing.html wseventing.xml
Log Message:
7160
Index: wseventing.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.xml,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -d -r1.68 -r1.69
--- wseventing.xml 26 Aug 2009 03:25:10 -0000 1.68
+++ wseventing.xml 26 Aug 2009 13:14:29 -0000 1.69
@@ -116,13 +116,13 @@
Web service (called a "subscriber") to register interest (called
a "subscription") with another Web service (called an "event
source") in receiving messages about events (called
- "notifications"). The subscriber may manage
+ "notifications"). The subscriber can manage
the subscription by interacting with a Web service (called the
"subscription manager") designated by the event source.
</p>
<p>
- To improve robustness, a subscription may be leased by an
+ To improve robustness, a subscription can be leased by an
event source to a subscriber, and the subscription expires over
time. The subscription manager provides the ability for the
subscriber to renew or cancel the subscription before it
@@ -130,7 +130,7 @@
</p>
<p>
- There are many mechanisms by which event sources may deliver
+ There are many mechanisms by which event sources can deliver
events to event sinks. This specification provides an extensible
way for subscribers to identify the delivery mechanism they
prefer.
@@ -171,7 +171,7 @@
<item>
<p>
- Allow subscribers to specify how notifications should be delivered.
+ Allow subscribers to specify how notifications are to be delivered.
</p>
</item>
@@ -214,7 +214,7 @@
This specification defines a method for transmitting notifications from
the event source to the event sink through the use of the wse:NotifyTo
element. Other
- methods or combination of methods may be defined through the use
+ methods or combination of methods MAY be defined through the use
of delivery extensions.
</p>
@@ -237,7 +237,7 @@
<p>
This specification specifies two delivery formats: wrapped and
unwrapped. Use of wrapped format indicates that notification messages
- should be contained in a wrapper element defined by this
+ MUST be contained in a wrapper element defined by this
specification. Use of unwrapped format indicates that notification
messages are not contained in a wrapper element.
</p>
@@ -255,15 +255,15 @@
<p>
In some scenarios the event source itself manages the
subscriptions it has created. In other scenarios, for example a
- geographically distributed publish-and-subscribe system, it may
+ geographically distributed publish-and-subscribe system, it might
be useful to delegate the management of a subscription to another
Web service. To support this flexibility, the response to a
subscription request to an event source will include the EPR of a
- service that the subscriber may interact with to manage this
- subscription. This EPR should be the target for future requests
- to renew or cancel the subscription. It may address the same Web
+ service that the subscriber MAY interact with to manage this
+ subscription. This EPR MUST be the target for future requests
+ to renew or cancel the subscription. It can address the same Web
service (Address and ReferenceParameters) as the event source
- itself, or it may address some other Web service to which the
+ itself, or it can address some other Web service to which the
event source has delegated management of this subscription;
however, the full subscription manager EPR (Address and Reference
Parameters) must be unique for each
@@ -331,12 +331,12 @@
</p>
<p>
- While lines (13-15) indicate where a reply should be sent,
- lines (20-29) indicate where and how notifications should be
+ While lines (13-15) indicate where a reply SHOULD be sent,
+ lines (20-29) indicate where and how notifications MUST be
delivered; there is no requirement that these match. The absence
of any extensions to the wse:Delivery or wse:NotifyTo elements
indicates that notifications
- should be sent as SOAP messages to the endpoint described in
+ MUST be sent as SOAP messages to the endpoint described in
lines (21-28). Note that lines (25-27) illustrate a typical
pattern where the event sink lists a reference parameter (line 26)
that identifies the subscription and will be included in each
@@ -765,11 +765,11 @@
<p>
When an event source accepts a request to create a
subscription, it typically does so for a given amount of time,
- although an event source may accept an indefinite subscription
+ although an event source MAY accept an indefinite subscription
with no time-based expiration. If the subscription manager
accepts a renewal request, it updates that amount of time. During
that time, notifications are delivered by the event source to the
- requested event sink. An event source may support filtering to
+ requested event sink. An event source MAY support filtering to
limit notifications that are delivered to the event sink; if it
does, and a subscribe request contains a filter, the event source
sends only notifications that match the requested filter. The
@@ -870,7 +870,7 @@
the delivery format to be used for notification messages sent in
relation to this subscription. Implied value is
"http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap", which
- indicates that unwrapped delivery should be used. See
+ indicates that unwrapped delivery MUST be used. See
Section <specref ref="NotificationFormats"/> for details.
</p>
@@ -909,7 +909,7 @@
implied value.) The event source defines the actual
expiration and is not constrained to use a time less or
greater than the requested expiration. The expiration time
- may be a specific time or a duration from the subscription's
+ MAY be a specific time or a duration from the subscription's
creation time. Both specific times and durations are
interpreted based on the event source's clock.
</p>
@@ -919,8 +919,8 @@
subscription that will not expire. That is, the subscriber is
requesting the event source to create a subscription with an
indefinite lifetime. If the event source grants such a
- subscription, it may be terminated by the subscriber using an
- Unsubscribe request, or it may be terminated by the event
+ subscription, it MAY be terminated by the subscriber using an
+ Unsubscribe request, or it MAY be terminated by the event
source at any time for reasons such as connection
termination, resource constraints, or system shut-down.
</p>
@@ -934,7 +934,7 @@
</p>
<p>
- Some event sources may not have a "wall time" clock
+ Some event sources might not have a "wall time" clock
available, and so are only able to accept durations as
expirations. If such a source receives a Subscribe request
containing a specific time expiration, then the request MAY
@@ -987,7 +987,7 @@
<p>
While an XPath predicate expression provides great
- flexibility and power, alternate filter dialects may be
+ flexibility and power, alternate filter dialects MAY be
defined. For instance, a simpler, less powerful dialect might
be defined for resource-constrained implementations, or a new
dialect might be defined to support filtering based on data
@@ -1131,8 +1131,8 @@
<p>
If this element does not appear, then the subscription
will not expire. That is, the subscription has an indefinite
- lifetime. It may be terminated by the subscriber using an
- Unsubscribe request, or it may be terminated by the event
+ lifetime. It MAY be terminated by the subscriber using an
+ Unsubscribe request, or it MAY be terminated by the event
source at any time for reasons such as connection
termination, resource constraints, or system shut-down.
</p>
@@ -2159,7 +2159,7 @@
<p>
This fault is generated when a Subscribe request specifies a filter
dialect that the event source does not support. Optionally, this
- fault may contain a list of supported filter dialect URIs in the
+ fault MAY contain a list of supported filter dialect URIs in the
Detail property.
</p>
@@ -2349,7 +2349,7 @@
<p>
This fault is generated when a Subscribe request specifies a delivery
format that is not supported by the event source. Optionally, this
- fault may contain a list of supported delivery format URIs in the
+ fault MAY contain a list of supported delivery format URIs in the
Detail property.
</p>
@@ -2471,15 +2471,15 @@
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
+ bodies, the <code><s12:Body></code> element SHOULD be
signed so content cannot be added in transit.
</p>
<p>
- Different security mechanisms may be desired depending on the
+ Different security mechanisms MAY be desired depending on the
frequency of messages. For example, for infrequent messages,
- public key technologies may be adequate for integrity and
- confidentiality. However, for high-frequency events, it may be
+ public key technologies MAY be adequate for integrity and
+ confidentiality. However, for high-frequency events, it MAY be
more performant to establish a security context for the events
using the mechanisms described in WS-Trust
<bibref ref="WSTrust"/> and WS-SecureConversation
@@ -2487,7 +2487,7 @@
</p>
<p>
- It should be noted that if a shared secret is used it is
+ 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.
</p>
@@ -2553,16 +2553,16 @@
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
+ care SHOULD be taken to ensure that minimal state is saved
prior to any authenticating sequences.
</p>
</item>
<item>
<p>
- Replay - Messages may be replayed
+ Replay - Messages might be replayed
for a variety of reasons. To detect and eliminate this
- attack, mechanisms should be used to identify replayed
+ 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
@@ -2629,9 +2629,9 @@
</p>
<p>
- Event sinks should be prepared to receive notifications after
+ Event sinks SHOULD be prepared to receive notifications after
sending a subscribe request but before receiving a subscribe
- response message. Event sinks should also be prepared to receive
+ response message. Event sinks SHOULD also be prepared to receive
notifications after receiving an unsubscribe response
message.
</p>
@@ -2831,7 +2831,7 @@
<p>
In order to obtain the event-related metadata that describes a
service, the mechanisms described in WS-MetadataExchange
- <bibref ref="MEX"/> should be used. The
+ <bibref ref="MEX"/> SHOULD be used. The
GetMetadata operation defined there allows WSDL and policy
information to be retrieved. The WSDL will contain annotations
that identify a service as an event source and that identify
@@ -2953,9 +2953,9 @@
As described here, to subscribe to events exposed by an event
source, a subscribing endpoint sends a Subscribe message to the
endpoint reference for the event source. If the Subscribe does
- not include a filter, the event sink should expect to receive
+ not include a filter, the event sink SHOULD expect to receive
events defined by notification operations within the portType and
- should expect to receive and respond to events defined by
+ SHOULD expect to receive and respond to events defined by
solicit-response operations within the portType.
</p>
@@ -2970,7 +2970,7 @@
<p>
A normative copy of the XML Schema <bibref ref='XMLSchema1'/>,
- <bibref ref='XMLSchema2'/> description for this specification may be
+ <bibref ref='XMLSchema2'/> description for this specification can be
retrieved from the following address:
</p>
@@ -3723,6 +3723,13 @@
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7235">7235</loc>
</td>
</tr>
+ <tr>
+ <td> 2009/08/26 </td>
+ <td> DD </td>
+ <td> Added resolution of issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7160">7160</loc>
+ </td>
+ </tr>
</tbody>
</table>
</div1>
Index: wseventing.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.html,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -d -r1.77 -r1.78
--- wseventing.html 26 Aug 2009 03:25:10 -0000 1.77
+++ wseventing.html 26 Aug 2009 13:14:28 -0000 1.78
@@ -105,17 +105,17 @@
Web service (called a "subscriber") to register interest (called
a "subscription") with another Web service (called an "event
source") in receiving messages about events (called
- "notifications"). The subscriber may manage
+ "notifications"). The subscriber can manage
the subscription by interacting with a Web service (called the
"subscription manager") designated by the event source.
</p><p>
- To improve robustness, a subscription may be leased by an
+ To improve robustness, a subscription can be leased by an
event source to a subscriber, and the subscription expires over
time. The subscription manager provides the ability for the
subscriber to renew or cancel the subscription before it
expires.
</p><p>
- There are many mechanisms by which event sources may deliver
+ There are many mechanisms by which event sources can deliver
events to event sinks. This specification provides an extensible
way for subscribers to identify the delivery mechanism they
prefer.
@@ -132,7 +132,7 @@
Define how an event source delegates subscription
management to another Web service.
</p></li><li><p>
- Allow subscribers to specify how notifications should be delivered.
+ Allow subscribers to specify how notifications are to be delivered.
</p></li><li><p>
Leverage other Web service specifications for secure,
reliable, transacted message delivery.
@@ -152,7 +152,7 @@
This specification defines a method for transmitting notifications from
the event source to the event sink through the use of the wse:NotifyTo
element. Other
- methods or combination of methods may be defined through the use
+ methods or combination of methods MAY be defined through the use
of delivery extensions.
</p><p>
When the wse:NotifyTo element is used within the Delivery element it
@@ -168,7 +168,7 @@
<h3><a name="NotificationFormats" id="NotificationFormats"/>2.3 Notification Formats</h3><p>
This specification specifies two delivery formats: wrapped and
unwrapped. Use of wrapped format indicates that notification messages
- should be contained in a wrapper element defined by this
+ MUST be contained in a wrapper element defined by this
specification. Use of unwrapped format indicates that notification
messages are not contained in a wrapper element.
</p><p>
@@ -179,15 +179,15 @@
<h3><a name="SubMgr" id="SubMgr"/>2.4 Subscription Managers</h3><p>
In some scenarios the event source itself manages the
subscriptions it has created. In other scenarios, for example a
- geographically distributed publish-and-subscribe system, it may
+ geographically distributed publish-and-subscribe system, it might
be useful to delegate the management of a subscription to another
Web service. To support this flexibility, the response to a
subscription request to an event source will include the EPR of a
- service that the subscriber may interact with to manage this
- subscription. This EPR should be the target for future requests
- to renew or cancel the subscription. It may address the same Web
+ service that the subscriber MAY interact with to manage this
+ subscription. This EPR MUST be the target for future requests
+ to renew or cancel the subscription. It can address the same Web
service (Address and ReferenceParameters) as the event source
- itself, or it may address some other Web service to which the
+ itself, or it can address some other Web service to which the
event source has delegated management of this subscription;
however, the full subscription manager EPR (Address and Reference
Parameters) must be unique for each
@@ -238,12 +238,12 @@
indicates that it is sent to a hypothetical event source of ocean
events.
</p><p>
- While lines (13-15) indicate where a reply should be sent,
- lines (20-29) indicate where and how notifications should be
+ While lines (13-15) indicate where a reply SHOULD be sent,
+ lines (20-29) indicate where and how notifications MUST be
delivered; there is no requirement that these match. The absence
of any extensions to the wse:Delivery or wse:NotifyTo elements
indicates that notifications
- should be sent as SOAP messages to the endpoint described in
+ MUST be sent as SOAP messages to the endpoint described in
lines (21-28). Note that lines (25-27) illustrate a typical
pattern where the event sink lists a reference parameter (line 26)
that identifies the subscription and will be included in each
@@ -432,11 +432,11 @@
</p><p>
When an event source accepts a request to create a
subscription, it typically does so for a given amount of time,
- although an event source may accept an indefinite subscription
+ although an event source MAY accept an indefinite subscription
with no time-based expiration. If the subscription manager
accepts a renewal request, it updates that amount of time. During
that time, notifications are delivered by the event source to the
- requested event sink. An event source may support filtering to
+ requested event sink. An event source MAY support filtering to
limit notifications that are delivered to the event sink; if it
does, and a subscribe request contains a filter, the event source
sends only notifications that match the requested filter. The
@@ -497,7 +497,7 @@
the delivery format to be used for notification messages sent in
relation to this subscription. Implied value is
"http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap", which
- indicates that unwrapped delivery should be used. See
+ indicates that unwrapped delivery MUST be used. See
Section <a href="#NotificationFormats"><b>2.3 Notification Formats</b></a> for details.
</p><p>
If the event source does not support the requested delivery
@@ -513,7 +513,7 @@
implied value.) The event source defines the actual
expiration and is not constrained to use a time less or
greater than the requested expiration. The expiration time
- may be a specific time or a duration from the subscription's
+ MAY be a specific time or a duration from the subscription's
creation time. Both specific times and durations are
interpreted based on the event source's clock.
</p><p>
@@ -521,8 +521,8 @@
subscription that will not expire. That is, the subscriber is
requesting the event source to create a subscription with an
indefinite lifetime. If the event source grants such a
- subscription, it may be terminated by the subscriber using an
- Unsubscribe request, or it may be terminated by the event
+ subscription, it MAY be terminated by the subscriber using an
+ Unsubscribe request, or it MAY be terminated by the event
source at any time for reasons such as connection
termination, resource constraints, or system shut-down.
</p><p>
@@ -532,7 +532,7 @@
generate a wse:InvalidExpirationTime fault indicating that an
invalid expiration time was requested.
</p><p>
- Some event sources may not have a "wall time" clock
+ Some event sources might not have a "wall time" clock
available, and so are only able to accept durations as
expirations. If such a source receives a Subscribe request
containing a specific time expiration, then the request MAY
@@ -565,7 +565,7 @@
Implied value is "http://www.w3.org/2009/02/ws-evt/Dialects/XPath10".
</p><p>
While an XPath predicate expression provides great
- flexibility and power, alternate filter dialects may be
+ flexibility and power, alternate filter dialects MAY be
defined. For instance, a simpler, less powerful dialect might
be defined for resource-constrained implementations, or a new
dialect might be defined to support filtering based on data
@@ -641,8 +641,8 @@
</p><p>
If this element does not appear, then the subscription
will not expire. That is, the subscription has an indefinite
- lifetime. It may be terminated by the subscriber using an
- Unsubscribe request, or it may be terminated by the event
+ lifetime. It MAY be terminated by the subscriber using an
+ Unsubscribe request, or it MAY be terminated by the event
source at any time for reasons such as connection
termination, resource constraints, or system shut-down.
</p></dd></dl><p>
@@ -1282,7 +1282,7 @@
<h3><a name="FilteringRequestedUnavailable" id="FilteringRequestedUnavailable"/>6.5 FilteringRequestedUnavailable</h3><p>
This fault is generated when a Subscribe request specifies a filter
dialect that the event source does not support. Optionally, this
- fault may contain a list of supported filter dialect URIs in the
+ fault MAY contain a list of supported filter dialect URIs in the
Detail property.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:FilteringRequestedUnavailable</td></tr><tr><td><b>[Reason]</b></td><td>The requested filter dialect is not supported.</td></tr><tr><td><b>[Detail]</b></td><td>
<wse:SupportedDialect> +
@@ -1318,7 +1318,7 @@
<h3><a name="DeliveryFormatRequestedUnavailable" id="DeliveryFormatRequestedUnavailable"/>6.10 DeliveryFormatRequestUnavailable</h3><p>
This fault is generated when a Subscribe request specifies a delivery
format that is not supported by the event source. Optionally, this
- fault may contain a list of supported delivery format URIs in the
+ fault MAY contain a list of supported delivery format URIs in the
Detail property.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:DeliveryFormatRequestedUnavailable</td></tr><tr><td><b>[Reason]</b></td><td>The requested delivery format is not supported.</td></tr><tr><td><b>[Detail]</b></td><td>
<wse:SupportedDeliveryFormat> +
@@ -1343,19 +1343,19 @@
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
+ bodies, the <code><s12:Body></code> element SHOULD be
signed so content cannot be added in transit.
</p><p>
- Different security mechanisms may be desired depending on the
+ Different security mechanisms MAY be desired depending on the
frequency of messages. For example, for infrequent messages,
- public key technologies may be adequate for integrity and
- confidentiality. However, for high-frequency events, it may be
+ public key technologies MAY be adequate for integrity and
+ confidentiality. However, for high-frequency events, it MAY 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>.
</p><p>
- It should be noted that if a shared secret is used it is
+ 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.
</p><p>
@@ -1395,12 +1395,12 @@
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
+ care SHOULD be taken to ensure that minimal state is saved
prior to any authenticating sequences.
</p></li><li><p>
- Replay - Messages may be replayed
+ Replay - Messages might be replayed
for a variety of reasons. To detect and eliminate this
- attack, mechanisms should be used to identify replayed
+ 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
@@ -1437,9 +1437,9 @@
renew request and response messages that are significantly larger
than expected network latency.
</p><p>
- Event sinks should be prepared to receive notifications after
+ Event sinks SHOULD be prepared to receive notifications after
sending a subscribe request but before receiving a subscribe
- response message. Event sinks should also be prepared to receive
+ response message. Event sinks SHOULD also be prepared to receive
notifications after receiving an unsubscribe response
message.
</p></div><div class="div1">
@@ -1546,7 +1546,7 @@
<h2><a name="Metadata" id="Metadata"/>A Service Metadata for Eventing</h2><p>
In order to obtain the event-related metadata that describes a
service, the mechanisms described in WS-MetadataExchange
- <a href="#MEX">[WS-MetadataExchange]</a> should be used. The
+ <a href="#MEX">[WS-MetadataExchange]</a> SHOULD be used. The
GetMetadata operation defined there allows WSDL and policy
information to be retrieved. The WSDL will contain annotations
that identify a service as an event source and that identify
@@ -1634,9 +1634,9 @@
As described here, to subscribe to events exposed by an event
source, a subscribing endpoint sends a Subscribe message to the
endpoint reference for the event source. If the Subscribe does
- not include a filter, the event sink should expect to receive
+ not include a filter, the event sink SHOULD expect to receive
events defined by notification operations within the portType and
- should expect to receive and respond to events defined by
+ SHOULD expect to receive and respond to events defined by
solicit-response operations within the portType.
</p><p>
Editor's Note: We anticipate that this WSDL extension
@@ -1644,7 +1644,7 @@
</p></div><div class="div1">
<h2><a name="Schema" id="Schema"/>B XML Schema</h2><p>
A normative copy of the XML Schema <a href="#XMLSchema1">[XML Schema, Part 1]</a>,
- <a href="#XMLSchema2">[XML Schema, Part 2]</a> description for this specification may be
+ <a href="#XMLSchema2">[XML Schema, Part 2]</a> description for this specification can be
retrieved from the following address:
</p><div class="exampleOuter"><div class="exampleInner"><pre><a href="http://www.w3.org/2009/02/ws-evt/eventing.xsd">http://www.w3.org/2009/02/ws-evt/eventing.xsd</a></pre></div></div><p>
A non-normative copy of the XML schema is listed below for
@@ -2081,4 +2081,5 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206">7206</a></td></tr><tr><td> 2009/08/25 </td><td> DD </td><td> Added resolution of issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7365">7365</a></td></tr><tr><td> 2009/08/25 </td><td> DD </td><td> Added resolution of issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7270">7270</a></td></tr><tr><td> 2009/08/25 </td><td> DD </td><td> Added resolution of issue
- <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7235">7235</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=7235">7235</a></td></tr><tr><td> 2009/08/26 </td><td> DD </td><td> Added resolution of issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7160">7160</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 26 August 2009 13:14:41 UTC