the following uses of "should" and "may" should be changed as noted:

Allow subscribers to specify how notifications should be delivered.
s/should/are to/

Use of wrapped format indicates that notification messages should be contained in a wrapper element.
s/should/MUST/

This EPR should be the target for future requests to renew or cancel the subscription.
s/should/MUST/

While lines (13-15) indicate where a reply should be sent,
s/should/SHOULD/

lines (20-29) indicate where and how notifications should be delivered;
s/should/MUST/

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 lines (21-28).
s/should/MUST/

Implied value is "http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap", which indicates that unwraped delivery should be used.
s/should/MUST/

For messages with empty bodies, the <code>&lt;s12:Body&gt;</code> element should be signed so content cannot be added in transit.
s/should/SHOULD/

It should be noted that if a shared secret is used it is RECOMMENDED that derived keys be used to strengthen the secret as described in WS-SecureConversation.
s/It should be noted that/Note that/

That said, care should be taken to ensure that minimal state is saved
prior to any authenticating sequences.
s/should/SHOULD/

To detect and eliminate this attack, mechanisms should be used to identify replayed messages such as the timestamp/nonce outlined in WS-Security.
s/should/SHOULD/

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 notifications after receiving an unsubscribe response message.
s/should/SHOULD/   2 of them

In order to obtain the event-related metadata that describes a service, the mechanisms described in WS-MetadataExchange <bibref ref="MEX"/> should be used.
s/should/SHOULD/

If the Subscribe does 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 solicit-response operations within the portType.
s/should/SHOULD/  2 of them

The subscriber may manage the subscription by interacting with a Web service (called the "subscription manager") designated by the event source.
s/may/can/

To improve robustness, a subscription may be leased by an event source to a subscriber, and the subscription expires over time.
s/may/can/

There are many mechanisms by which event sources may deliver events to event sinks.
s/may/can/

Other methods or combination of methods may be defined through the use of delivery extensions.
s/may/MAY/

In other scenarios, for example a geographically distributed publish-and-subscribe system, it may be useful to delegate the management of a subscription to another Web service. 
s/may/might/

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.
s/may/MAY/

It may address the same Web service (Address and ReferenceParameters) as the event source itself, or it may address some other Web service to which the event source has delegated management of this subscription;
s/may/can/  2 of them

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 with no time-based expiration. 
s/may/MAY/

An event source may support filtering to limit notifications that are delivered to the event sink;
s/may/MAY/

The expiration time may be a specific time or a duration from the subscription's
creation time.
s/may/MAY/

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
source at any time for reasons such as connection termination, resource constraints, or system shut-down.
s/may/MAY/  2 of them

Some event sources may not have a "wall time" clock available, and so are only able to accept durations as expirations. 
s/may/might/

While an XPath predicate expression provides great flexibility and power, alternate filter dialects may be defined. 
s/may/MAY/

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.
s/may/MAY/  2 of them

If neither is present faults may be sent to the [source endpoint].
Remove this sentence since its wrong for WSA REC.

Optionally, this fault may contain a list of supported filter dialect URIs in the Detail property.
s/may/MAY/

Optionally, this fault may contain a list of supported delivery format URIs in the Detail property.
s/may/MAY/

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 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"/>.
s/may/might/   3 of them

Replay  - Messages may be replayed for a variety of reasons. 
s/may/might/

A normative copy of the XML Schema <bibref ref='XMLSchema1'/>, <bibref ref='XMLSchema2'/> description for this specification may be retrieved from the following address:
s/may/can/


for the s/should/SHOULD/ and s/may/MAY/ cases, while I know the case doesn't matter, making them SHOULD will be a sign that we did it on purpose, while the 
lowercase "should"s are ones that we added w/o thinking about it fully.