[Bug 6696] New: Eventing: When to check the EPRs

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

           Summary: Eventing: When to check the EPRs
           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


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.


-- 
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 Friday, 13 March 2009 12:39:21 UTC