This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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