[Bug 7160] New: Eventing:should not use should or may

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7160

           Summary: Eventing:should not use should or may
           Product: WS-Resource Access
           Version: FPWD
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Eventing
        AssignedTo: public-ws-resource-access-notifications@w3.org
        ReportedBy: dug@us.ibm.com
         QAContact: public-ws-resource-access-notifications@w3.org


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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

Received on Tuesday, 28 July 2009 23:40:56 UTC