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 7039 - Eventing: wse:Identifier is asking for trouble
Summary: Eventing: wse:Identifier is asking for trouble
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-06-22 12:32 UTC by Doug Davis
Modified: 2009-08-18 21:18 UTC (History)
1 user (show)

See Also:


Attachments

Description Doug Davis 2009-06-22 12:32:25 UTC
WS-Eventing defines wse:Identifier as a ref-param that can be used.
However, we've already seen hints that some people's implementations,
in the past, were built with the assumption that this ref-param would
be there. This is incorrect.  We should reduce unnecessary interop
problems like this.

Proposal 1:
--------------------------------------------------------------
Remove the wse:Identifier element - people can define any kind of
ref-param they need.

Proposal 2:
--------------------------------------------------------------
Add clarifying text, after each use.  For example, section 4.1 says:

Note, subscribers wishing to correlate SubscriptionEnd messages with the subscription to which they apply MAY wish to add a distinguishing reference parameter to the EndTo EPR. For convenience in this common situation, this specification defines a global element, wse:Identifier of type xs:anyURI, that MAY be used as a distinguishing reference parameter.  

Add:
Implementations of Event Sources, or Subscription Managers, MUST NOT assume that this reference parameter will be used.

And do something similar for the SubscriptionMgr epr defn.
--------------------------------------------------------------

I prefer proposal 1 as it doesn't lead some less experienced developers down the wrong path.
Comment 1 Li Li 2009-06-23 17:12:08 UTC
quick questions. 
1) if we take proposal 1, how would a subscription manager distinguish different subscriptions it has?

2) in proposal 2, is the added statement consistent with the WS-Addressing guideline that the reference parameters are supposed to be opaque? In this case, the subscription manager minted an EPR (that contains wse:Identifier) and the event subscriber is supposed to always copy the reference parameters back when getstatus/renew/unsubscribe. 

Thanks.
Comment 2 Robert Freund 2009-07-08 06:11:45 UTC
2009-07-07 resolved by comment 1 proposal 1 "Remove the wse:Identifier element"