Web Services Resource Access Working Group Teleconference -- 07 Apr 2009

<trackbot> Date: 07 April 2009

<Bob> scribenick Ram

<Bob> scribenick: Ram

No objections to agenda. Agenda approved.

No objections to approving minutes from March 31, 2009. Minutes approved.

<dug> funny how [4] in the agenda is blank

RESOLUTION: No objections to approving minutes from March 31, 2009. Minutes approved.
... No objections to agenda. Agenda approved.

<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0020.html

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 to Closed.
... Do this by next week!

<dug> looks like a cool tool

<asir> agree

Bob: Discovery of diff service is a God send!

<dug> can we get a link to the wiki on the wsra home page?

<Bob> http://www.w3.org/2002/ws/ra/wiki/Main_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 has a way to consolidate arguments on technical issues in one place.

Correction: Wiki does not have a way, but it allows for such consolidation.

Issues discussion

Issue 6730

6730

<dug> latest updated proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0017.html

Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0024.html

<li> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730

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].

6715

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6715

RESOLUTION: Issue 6715 resolved with proposal in Bugzilla.

6725

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6725

<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6725#c1

Suggested change:

<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.�.

<asir> Re-paste

<gpilz> +1 to use of "Notification" consistently

<Bob> Proposal:

<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 [1]: 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 [1]: In the definition of “Subscription Manager”: Change “A

<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.”.

<Bob> [1] http://www.w3.org/TR/2009/WD-ws-eventing-20090317/#terms

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 respod 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].

6727

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6727

<Wu> goog pick,

<gpilz> good even

<Wu> ops , good pick

<asir> Replace UnSubscribeResponse with UnsubscribeResponse

6726

<asir> Asir: use a similar template to 6727 to resolve 6726

RESOLUTION: Issue 6726 is resolved.

6728

RESOLUTION: Issue 6728 is resolved.

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.

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html

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.

<Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0033.html

Gil: I beleive Doug has provide credible examples.

<Bob> ack track wu

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 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 proposals.
... 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: It 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 headers.
... 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.
... 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 opposite.
... 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"

<asir> Please!

Bob: At some point, we need to reach consensus.
... otherwise, we want to pull the plug on consensus.

- DRAFT -

Web Services Resource Access Working Group Teleconference

07 Apr 2009

Attendees

Contents