6696 2009-03-13 12:39:11 +0000 Eventing: When to check the EPRs 2009-06-24 00:04:22 +0000 1 1 1 Unclassified WS-Resource Access Eventing FPWD PC Windows XP CLOSED REMIND hasProposal P2 normal --- 1 dug dug public-ws-resource-access-notifications oldest_to_newest 24228 0 dug 2009-03-13 12:39:11 +0000 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. 25123 1 bob 2009-05-13 07:55:42 +0000 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. 25136 2 dug 2009-05-13 13:28:31 +0000 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