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 6696 - Eventing: When to check the EPRs
Summary: Eventing: When to check the EPRs
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Doug Davis
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: hasProposal
Depends on:
Blocks:
 
Reported: 2009-03-13 12:39 UTC by Doug Davis
Modified: 2009-06-24 00:04 UTC (History)
0 users

See Also:


Attachments

Description Doug Davis 2009-03-13 12:39:11 UTC
WS-Eventing defines the NotifyTo and EndTo EPRs but its not clear 
when these EPRs are checked for validity. For example, do they contain
valid URIs (not just syntactically but does the event source support
the transport), does the event source support any policy assertions
specified within the EPR, stuff like this.

Clearly some of problems that could exist with an EPR might not be
detectable until the sender tries to use the EPR (e.g. a 404) but there
are some things that could be checked at a superficial level during
the processing of the Subscribe - for example, checking to make sure
the wsa:Address IRI specifies a transport that the event source can
support. 

Proposal:
Add the following to the WS-Eventing spec at the end of the Subscribe request
defn/text:

- - - - - - - - -
If included within the Subscribe request message, the wse:NotifyTo 
and wse:EndTo SHOULD have some cursory validity checking performed before 
the Subscribe response is returned. While not all errors can be detected
prior to sending a message to those EPRs, some obvious ones can be detected.
For example, an unsupported transport specified within the wsa:Address IRI.
Detecting these errors during Subscribe processing will lessen the chances
of the subscriber creating an unusable subscription.  If this check is
performed and an problem is detected then the event source MUST generate
a wse:InvalidEPR fault rather than returning the SubscribeResponse message.
- - - - - - - - -

and then define a wse:InvalidEPR fault - make the details element
say which EPR(s) was bad and why.  We can't use the wsa:InvalidEPR fault 
because that appears to only be for headers - no idea why  ;-)

If we accept this proposal then we should apply the same type of
change to WS-Enumeration (wsen:EndTo) as well - for consistency.
Comment 1 Robert Freund 2009-05-13 07:55:42 UTC
Resolution:
Add the following to the WS-Eventing spec at the end of the Subscribe request
defn/text:

- - - - - - - - -
If included within the Subscribe request message, the wse:NotifyTo 
and wse:EndTo SHOULD have some cursory validity checking performed before 
the Subscribe response is returned. While not all errors can be detected
prior to sending a message to those EPRs, some obvious ones can be detected.
For example, an unsupported transport specified within the wsa:Address IRI.
Detecting these errors during Subscribe processing will lessen the chances
of the subscriber creating an unusable subscription.  If this check is
performed and a problem is detected then the event source MAY generate
a wse:UnusableEPR fault rather than returning the SubscribeResponse message.
- - - - - - - - -

and then define a wse:UnusableEPR fault - make the details element
say which EPR(s) was bad and why.  We can't use the wsa:InvalidEPR fault 
because that appears to only be for headers - no idea why  ;-)

If we accept this proposal then we should apply the same type of
change to WS-Enumeration (wsen:EndTo) as well - for consistency.
Comment 2 Doug Davis 2009-05-13 13:28:31 UTC
Resolved with proposal + these changes:

change s/and an problem is detected/and a problem is detected/
also change MUST/MAY
and s/InvalidEPR/UnusableEPR

and do it in Enum too.

5/12/09 meeting