This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8288 - Eventing: requirements on Notification Bindings for EventDescriptions too lax
Summary: Eventing: requirements on Notification Bindings for EventDescriptions too lax
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: hasProposal
Depends on:
Blocks:
 
Reported: 2009-11-13 21:57 UTC by Gilbert Pilz
Modified: 2010-03-17 10:55 UTC (History)
1 user (show)

See Also:


Attachments

Description Gilbert Pilz 2009-11-13 21:57:32 UTC
Section A.1.2 "Bindings for EventDescriptions" contains the following paragraph:

"For any Notification Format it SHOULD be possible to determine how a given wse:eventType will appear on the wire as a notification in a subscription created with that format. The following sections define how wse:eventTypes bind to notifications for the two Notification Formats defined in this specification; Unwrapped and Wrapped. Specifications or profiles that define additional Notification Formats SHOULD define how wse:eventTypes bind to the notifications for those formats. In the absence of a mapping for a particular Notification Format, implementations MAY provide a Notification WSDL (see below) that explicitly describes the notification operations."

This allows for the possibility of Notification Formats for which there is no well defined mapping from a wse:eventType to the on-the-wire notification. This completely undoes the entire purpose of EventDescriptions, which is to enable the event sink to determine how notifications will appear.

Proposal: s/SHOULD/MUST/ in the above paragraph
Comment 1 Doug Davis 2009-11-17 21:59:21 UTC
applies to both SHOULDs
s/SHOULD/MUST/g
Comment 2 Robert Freund 2010-01-26 19:29:01 UTC
resolved as proposed as amended by comment #1