See also: IRC log
<trackbot> Date: 07 April 2009
<Bob> scribe: Ram Jeyaraman
<Bob> scribenick: Ram
No objections to agenda. Agenda approved.
<dug> funny how  in the agenda is blank
objections to approving minutes from March 31, 2009. Minutes
... No objections to agenda. Agenda approved.
Gil has not reviewed the April snapshots. Everyone is encouraged to read and discuss the issues in question.
<dug> gil's your straightman :-)
Bob: Please review the latest revision of the specifications.
Asir: Is the diff between the submitted version and the latest version?
Bob explains how the diff works.
<asir> Bob's page is at http://www.w3.org/2002/ws/ra/EdDiffFPWD.html
Yves: Can we record in each issue all the notification URIs (and diffs) associated with each issue?
Bob: Do the editors have an opinion?
Doug: It sounds like a lot of work.
Yves: There are some advantages such as backtracking ,etc.
Doug: Editors have been committing at most one issue per commit. Hence, the CVS comment field notifications should suffice.
<dug> automagic is good :-)
<asir> Sounds like it can be automated!
Asir: Will we continue to have HTML diff versions?
Bob says the diff service tools allow for this.
Bob: Review the diffs and the change
logs so we can change the state of incorporated issues from Remind
... Do this by next week!
<dug> looks like a cool tool
Bob: Discovery of diff service is a God send!
<dug> can we get a link to the wiki on the wsra home page?
Bob: We have a Wiki for the WG set up. The link is in the agenda.
Doug: Question for Yves. Does Wiki page send notifications?
Bob: Wiki provides a space to allow for consolidation of arguments on technical issues in one place.
<dug> latest updated proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0017.html
AI: Ram to prepare the consolidated proposal.
<Bob> ACTION: Ram to consolidate 6730 proposals for consideration next time [recorded in http://www.w3.org/2009/04/07-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-54 - Consolidate 6730 proposals for consideration next time [on Ram Jeyaraman - due 2009-04-14].
<asir> ACTION: Ram to prep a consolidated proposal for issue 6730 [recorded in http://www.w3.org/2009/04/07-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-55 - Prep a consolidated proposal for issue 6730 [on Ram Jeyaraman - due 2009-04-14].
RESOLUTION: Issue 6715 resolved with proposal in Bugzilla.
<asir> This is in Section 3.3
<asir> In the definition of ÒDelivery ModeÓ, change ÒThe mechanism by which event messages are delivered from the source to the sinkÓ to ÒThe mechanism by which event messages (or notifications) are delivered from the source to the sink.Ó.
<gpilz> +1 to use of "Notification" consistently
<Bob> Change all uses of "event messages" with "notifications". The first use will
<Bob> actually just be deleted since "notifications" is already in that sentence.
<Bob> Suggested change:
<Bob> - Section 3.3 : In the definition of 'Delivery Mode', change 'The
<Bob> mechanism by which event messages are delivered from the source to the sink' to
<Bob> 'The mechanism by which event notifications are delivered from
<Bob> the source to the sink'.
<Bob> - Section 3.3 : In the definition of 'Subscription Manager': Change
<Bob> 'Web service that accepts requests to manage get the status of, renew, and/or
<Bob> delete subscriptions on behalf of an event source.' To 'A Web service that
<Bob> accepts requests to create, get the status of, renew,
<Bob> and/or delete
<Bob> subscriptions on behalf of an event source.'.
RESOLUTION: Issue 6725 has been resolved as proposed with a merger of Doug's proposal and Ram's. Further, use the term 'notification' consistently.
<Bob> ACTION: Dug to respond to reviewer on 6725 [recorded in http://www.w3.org/2009/04/07-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-56 - Respod to reviewer on 6725 [on Doug Davis - due 2009-04-14].
<Wu> good pick,
<gpilz> good even
<Wu> ops , good pick
<asir> Replace UnSubscribeResponse with UnsubscribeResponse
RESOLUTION: Issue-6727 resolved with proposal in bugzilla comment#1
<asir> Asir: use a similar template to 6727 to resolve 6726
RESOLUTION: Issue 6726 is resolved as proposed in bugzilla.
RESOLUTION: Issue 6728 is resolved as proposed in bugzilla.
Bob: We are not close to resolving the issue on Delivery Mode.
Tom: It is clear to me that one
faction thinks that the spec output is wire compatible with the
older versions but the other faction thinks not.
... Need to make the specifications work with other WS-* specifications.
Wu: We need to provide compatibility as much as possible.
Bob; Is there a commonality between the proposals?
Wu: Removal of Delivery Mode will
cause significant change to existing implementations.
... Is there a problem with the existing Delivery Mode semantics?
<dug> queue please
Asir: The justification to drop
Delivery Mode abstration is redundancy.
... Delivery Mode is not redundant.
... I have not seen a credible alternative yet.
Asir: If there is a credible alternative that will help us build consensus.
Doug: I explained how Delivery Mode
does not work.
... It is a functional problem we are trying to fix. I sent this via email.
Gil: I beleive Doug has provide credible examples.
Wu: I have posted a response to Doug's email.
<dug> Wu's email does not address the technical issues I raised
Wu: Yes, you can use SOAP headers to
signify mode of use.
... The WS-Eventing specification already allows use of SOAP headers.
... I don't think anything is broken.
<dug> Wu's proposal: all Modes need to define mU header and a Mode attribute URI
Wu: If we remove the Delivery Mode attribute, it will break current implementations. I don't see any benefit to doing so.
<TRutt> every example of mode use seen so far by me can be accomodated with ws-* composition. I suggest we remove it now and only introduce such a feature later when ws-eventing has its own use case which cannot be satisfied with ws-* composition
<asir> OUr response to Tom is here http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0023.html
Bob: Summarizes the two sides of the argument.
<asir> But, neither the delivery mode abstraction nor the mode attribute indicates what Web Services technologies (such as reliable messaging, security features, SOAP version, transport binding and make connection) should be used (or composed) to deliver events.
<asir> Please find a description of what does a delivery mode indicate and why it is essential at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0132.html
Bob: There are two different
... Is one proposal to close this issue with no action.
Asir, Wu: Correct.
<dug> WHAT FEATURE?
<asir> Read mail archive
<gpilz> yadda yadda yadda
<gpilz> read it
Bob: The argument against removing Delivery Mode is that removes a valuable feature.
<gpilz> it's all still there
Doug: Show us the solid use case to show why Delivery Mode is needed.
<asir> We provided use cases from the DMTF WS-Man Standard DSP 226
<asir> s/read mail archive/http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0132.html/
<gpilz> ever one of those use cases can be supported via standard SOAP and WS-Addressing mechanisms
Doug: We provided a proposal to solve the composition problem where there are non-conflicting modes.
<gpilz> none of them require a unique "Mode" attribute
Doug: This is causing people problems.
<gpilz> WS-* is based on the orthogonal composition of . . . what's the point?
<gpilz> nobody is listening
Wu: Can we use both SOAP headers and Delivery Mode, correct?
Doug: Existing mode extensibility mechanism will probably not work as described in WS-Eventing.
Wu: WS-Eventing allows use of SOAP
... in addition to Delivery Mode attribute.
<dug> yes - other specs (like RM) use soap headers to extend itself
Wu: Question to Yves: Is is OK to use SOAP header in this way to extend the delivery mode semantics.
Bob: The question really is whether we really want to foster the behavior of overloading the URI? Or do we need another mechanism? Or provide both?
<TRutt> ws man mode definitions can be handled using ws-makeconnection, ws-reliable-messaging and the new batching feature of our current draft for ws-eventing. My concern is that the next gen of ws-man should not have features which are redundant with those already accomplished by an orthogonal set of ws-* specs. Allowing such app spec specific redundancy in its spec seems to be of little benefit.
Tom: My concern is that I want WS-Man NOT to have features that are redundant. It will make it more difficult.
Bob: We can leave the existing mechanism and deprecate it.
Gil: I have concerns on
interoperability. Wu says that mode attribute is an extensibility
point and is advancing it as a good thing. In my mind it is the
... Giving so many options causes interoperability problems.
... Duplicating extensibility points is not a good thing.
<Yves> interop against extensibility is an unsolvable issue anyway
<dug> Wu: this is a SOAP spec - I don't get it
Wu: On Tom's point. The standard semantics should be relatively independent. Now we are trying to move the eventing semantics in to SOAP headers. This will be a problem going forward years from now.
<gpilz> WS-Eventing beyond SOAP is outside our charter
<gpilz> *way* outside our charter
<dug> we talk about mU headers in other parts of the spec -should we remove those?
<gpilz> Yves: the problem is that, to tell whether or not a message has been extended I need to check 8 different places
<Wu> SOAP extension is allowed and you will see strange things.
Asir: We want to have a good reason to change the Delivery Mode mechanism.
<dug> Been provided - but ignored
Doug: The examples have been provided earlier.
<gpilz> asir: it doesn't seem likely that there would be any reason good enough to meet your criteria of "sufficient"
Bob: At some point, we need to reach
... otherwise, we want to pull the plug on consensus and make a decision. We can't wait forever.
Bob asks the WG members to review the irc carefully and make sure everything is properly scribed.