IRC log of ws-ra on 2009-04-07

Timestamps are in UTC.

19:21:07 [RRSAgent]
RRSAgent has joined #ws-ra
19:21:07 [RRSAgent]
logging to
19:21:09 [trackbot]
RRSAgent, make logs public
19:21:09 [Zakim]
Zakim has joined #ws-ra
19:21:11 [trackbot]
Zakim, this will be WSRA
19:21:11 [Zakim]
ok, trackbot, I see WS_WSRA()3:30PM already started
19:21:12 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
19:21:12 [trackbot]
Date: 07 April 2009
19:21:52 [Bob]
19:23:55 [Bob]
regrets+ Mark Little
19:24:42 [Zakim]
19:27:46 [Vikas]
Vikas has joined #ws-ra
19:28:17 [dug]
dug has joined #ws-ra
19:28:53 [Zakim]
19:29:11 [li]
li has joined #ws-ra
19:29:47 [Wu]
Wu has joined #ws-ra
19:29:59 [Zakim]
19:30:01 [Zakim]
19:30:35 [Zakim]
19:30:48 [Zakim]
19:31:10 [Bob]
zakim, Wu has li
19:31:10 [Zakim]
+li; got it
19:31:40 [asir]
asir has joined #ws-ra
19:31:50 [Ashok]
Ashok has joined #ws-ra
19:32:12 [Zakim]
19:32:19 [Zakim]
19:32:40 [Bob]
zakim, [Micro is Ram
19:32:40 [Zakim]
+Ram; got it
19:32:45 [gpilz]
gpilz has joined #ws-ra
19:33:37 [Bob]
zakim, Ram has Asir
19:33:37 [Zakim]
+Asir; got it
19:35:32 [asir]
asir has joined #ws-ra
19:35:47 [Ram]
Ram has joined #ws-ra
19:36:03 [Bob]
scribenick Ram
19:36:24 [Bob]
scribenick: Ram
19:37:01 [Ram]
No objections to agenda. Agenda approved.
19:37:30 [Ram]
No objections to approving minutes from March 31, 2009. Minutes approved.
19:37:38 [dug]
funny how [4] in the agenda is blank
19:37:46 [Ram]
RESOLUTION: No objections to approving minutes from March 31, 2009. Minutes approved.
19:38:03 [Ram]
RESOLUTION: No objections to agenda. Agenda approved.
19:38:57 [Bob]
19:40:01 [gpilz]
19:40:36 [Bob]
ack gp
19:41:02 [Ram]
Gil has not reviewed the April snapshots. Everyone is encouraged to read and discuss the issues in question.
19:41:05 [asir]
19:41:06 [dug]
gil's your straightman :-)
19:41:49 [Zakim]
19:41:57 [Bob]
ack asir
19:41:57 [Ram]
Bob: Please review the latest revision of the specifications.
19:42:01 [Zakim]
19:42:20 [Ram]
Asir: Is the diff between the submitted version and the latest version?
19:43:01 [Ram]
Bob explains how the diff works.
19:43:08 [Bob]
ack yves
19:43:16 [asir]
Bob's page is at
19:44:21 [Ram]
Yves: Can we record in each issue all the notification URIs (and diffs) associated with each issue?
19:44:45 [Ram]
Bob; Do the editors have an opinion?
19:44:54 [Ram]
Doug: It sounds like a lot of work.
19:45:28 [Ram]
Yves: There are some advantages such as backtracking ,etc.
19:46:08 [Ram]
Doug: Editors have been committing at most one issue per commit. Hence, the CVS comment field notifications should suffice.
19:46:39 [dug]
automagic is good :-)
19:46:48 [asir]
Sounds like it can be automated!
19:47:12 [Ram]
Asir: Will we continue to have HTML diff versions?
19:47:43 [Ram]
Bob says the diff service tools allow for this.
19:49:28 [Ram]
Bob: Review the diffs and the change logs so we can change the state of incorporated issues from Remind to Closed.
19:49:41 [Ram]
Bob: Do this by next week!
19:49:47 [dug]
looks like a cool tool
19:49:51 [asir]
19:49:58 [Ram]
Bob: Discovery of diff service is a God send!
19:50:18 [dug]
can we get a link to the wiki on the wsra home page?
19:50:25 [Bob]
19:50:29 [Ram]
Bob:We have a Wiki for the WG set up. The link is in the agenda.
19:50:58 [dug]
19:51:23 [Bob]
ack dug
19:51:49 [Ram]
Doug: Question for Yves. Does Wiki page send notifications?
19:53:46 [Ram]
Bob: Wiki has a way to consolidate arguments on technical issues in one place.
19:54:15 [Ram]
Correction: Wiki does not have a way, but it allows for such consolidation.
19:54:39 [Ram]
Issues discussion
19:54:43 [Ram]
Issue 6730
19:54:46 [Bob]
Topic: 6730
19:55:06 [dug]
latest updated proposal:
19:55:56 [Ram]
19:56:05 [Ram]
19:56:30 [Bob]
ack ram
19:56:41 [li]
19:57:11 [Ram]
AI: Ram to prepare the consolidated proposal.
19:57:29 [Bob]
action: Ram to consolidate 6730 proposals for consideration next time
19:57:29 [trackbot]
Created ACTION-54 - Consolidate 6730 proposals for consideration next time [on Ram Jeyaraman - due 2009-04-14].
19:57:30 [asir]
Action: Ram to prep a consolidated proposal for issue 6730
19:57:30 [trackbot]
Created ACTION-55 - Prep a consolidated proposal for issue 6730 [on Ram Jeyaraman - due 2009-04-14].
19:58:14 [Bob]
Topic: 6715
19:58:28 [Bob]
19:59:50 [asir]
RRSAgent, where am I?
19:59:50 [RRSAgent]
20:00:07 [Ram]
RESOLUTION: Issue 6715 resolved with proposal in Bugzilla.
20:00:18 [Ram]
Topic: 6725
20:00:38 [Bob]
20:00:50 [dug]
20:01:25 [asir]
q+ Ram
20:01:28 [Ram]
20:01:45 [Bob]
ack ram
20:02:53 [Ram]
Suggested change:
20:04:17 [asir]
This is in Section 3.3
20:04:19 [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.”.
20:04:30 [CGI471]
CGI471 has joined #ws-ra
20:04:41 [asir]
20:04:42 [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.”.
20:06:51 [CGI471]
CGI471 has joined #ws-ra
20:08:01 [Ram]
Ram has joined #ws-ra
20:08:59 [dug]
20:09:27 [Bob]
ack dug
20:10:20 [gpilz]
+1 to use of "Notification" consistently
20:12:41 [Bob]
20:12:42 [Bob]
Change all uses of "event messages" with "notifications". The first use will
20:12:44 [Bob]
actually just be deleted since "notifications" is already in that sentence.
20:12:45 [Bob]
Suggested change:
20:12:47 [Bob]
• Section 3.3 [1]: In the definition of “Delivery Mode”, change “The
20:12:48 [Bob]
mechanism by which event messages are delivered from the source to the sink” to
20:12:51 [Bob]
“The mechanism by which event notifications are delivered from
20:12:53 [Bob]
the source to the sink.”.
20:12:54 [Bob]
• Section 3.3 [1]: In the definition of “Subscription Manager”: Change “A
20:12:56 [Bob]
Web service that accepts requests to manage get the status of, renew, and/or
20:12:57 [Bob]
delete subscriptions on behalf of an event source.” To “A Web service that
20:12:59 [Bob]
accepts requests to create, get the status of, renew,
20:13:44 [Bob]
and/or delete
20:13:46 [Bob]
subscriptions on behalf of an event source.”.
20:13:47 [Bob]
20:15:05 [Ram]
RESOLUTION: Issue 6725 has been resolved as proposed with a merger of Doug's proposal and Ram's. Further, use the term 'notification' consistently.
20:15:37 [Bob]
action: Dug to respod to reviewer on 6725
20:15:37 [trackbot]
Created ACTION-56 - Respod to reviewer on 6725 [on Doug Davis - due 2009-04-14].
20:16:24 [Ram]
Topic: 6727
20:16:38 [Bob]
20:16:51 [asir]
q+ Ram
20:16:54 [Ram]
20:16:57 [Wu]
goog pick,
20:17:07 [gpilz]
good even
20:17:13 [Bob]
ack ram
20:17:13 [Wu]
ops , good pick
20:17:37 [gpilz]
20:17:45 [Bob]
zakim, who is making noise
20:17:45 [Zakim]
I don't understand 'who is making noise', Bob
20:17:51 [Bob]
zakim, who is making noise?
20:18:03 [Zakim]
Bob, listening for 10 seconds I heard sound from the following: Doug_Davis (47%), Gilbert (9%), Ram (33%), Ashok_Malhotra (13%)
20:18:54 [Bob]
ack gp
20:20:40 [li]
20:21:08 [Bob]
ack li
20:21:44 [Zakim]
20:21:53 [asir]
Replace UnSubscribeResponse with UnsubscribeResponse
20:23:10 [Bob]
Topic: 6726
20:23:26 [asir]
20:24:02 [Bob]
ack asir
20:24:09 [Ashok]
20:24:56 [Bob]
ack ashok
20:25:11 [asir]
Asir: use a similar template to 6725 to resolve 6726
20:25:43 [asir]
20:26:22 [Ram]
RESOLUTION: Issue 6726 is resolved.
20:27:39 [asir]
20:27:52 [Bob]
Topic: 6728
20:28:04 [Bob]
ack asir
20:28:22 [Ram]
RESOLUTION: Issue 6728 is resolved.
20:29:24 [gpilz]
20:29:32 [TRutt]
20:29:37 [Ram]
Bob: We are not close to resolving the issue on Delivery Mode.
20:29:45 [Bob]
ack gp
20:30:12 [Bob]
ack tru
20:30:33 [asir]
20:30:46 [Ram]
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.
20:31:02 [Wu]
20:31:27 [Ram]
Tom: Need to make the specifications work with other WS-* specifications.
20:31:46 [Bob]
ack asir
20:32:21 [Bob]
ack wu
20:33:30 [Ram]
Wu: We need to provide compatibility as much as possible.
20:34:15 [Wu]
20:34:16 [Ram]
Bob; Is there a commonality between the proposals?
20:34:24 [Bob]
ack wu
20:34:28 [asir]
20:34:50 [Ram]
Wu: Removal of Delivery Mode will cause significant change to existing implementations.
20:35:06 [dug]
20:35:25 [Ram]
Wu: Is there a problem with the existing Delivery Mode semantics?
20:36:23 [dug]
queue please
20:36:33 [Bob]
ack asir
20:36:45 [Ram]
Asir: The justification to drop Delivery Mode abstration is redundancy.
20:37:04 [Ram]
Asir: Delivery Mode is not redundant.
20:37:19 [Ram]
Asir: I have not seen a credible alternative yet.
20:37:48 [dug]
20:37:49 [Bob]
ack dug
20:37:57 [Ram]
Asir: If there is a credible alternative that will help us build consensus.
20:38:30 [gpilz]
20:38:35 [Ram]
Doug: I explained how Delivery Mode does not work.
20:38:36 [TRutt]
20:39:20 [Ram]
Doug: It is a functional problem we are trying to fix. I sent this via email.
20:39:32 [Bob]
ack gp
20:39:47 [Wu]
20:39:56 [Wu]
20:40:13 [Ram]
Gil: I beleive Doug has provide credible examples.
20:40:50 [Bob]
ack track wu
20:40:57 [Bob]
ack wu
20:40:58 [Ram]
Wu: I have posted a response to Doug's email.
20:41:18 [dug]
Wu's email does not address the technical issues I raised
20:41:24 [Ram]
Wu: Yes, you can use SOAP headers to signify mode of use.
20:41:41 [Ram]
Wu: The WS-Eventing specification already allows use of SOAP headers.
20:41:52 [Ram]
Wu: I don't think anything is broken.
20:41:55 [dug]
Wu's proposal: all Modes need to define mU header and a Mode attribute URI
20:42:16 [Ram]
Wu: If we remove the Delivery Mode attribute, it will break current implementations. I don't any benefit to doing so.
20:42:22 [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
20:42:26 [Bob]
ack tr
20:42:38 [asir]
20:42:47 [dug]
20:42:50 [Wu]
20:43:19 [asir]
20:43:58 [asir]
OUr response to Tom is here
20:44:58 [Ram]
Bob: Summarizes the two sides of the argument.
20:45:49 [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.
20:45:49 [asir]
Please find a description of what does a delivery mode indicate and why it is essential at
20:46:23 [Wu]
20:46:42 [Ram]
Bob: There are two different proposals.
20:47:02 [Ram]
Bob: Is one proposal to close this issue with no action.
20:47:19 [Ram]
Asir, Wu: Correct.
20:47:45 [dug]
20:47:53 [asir]
Read mail archive
20:48:09 [gpilz]
yadda yadda yadda
20:48:11 [gpilz]
read it
20:48:11 [Ram]
Bob: It removes a valuable feature.
20:48:16 [gpilz]
it's all still there
20:48:32 [Bob]
20:49:07 [Ram]
Doug: Show us the solid use case to show why Delivery Mode is needed.
20:49:41 [TRutt]
20:49:43 [asir]
We provided use cases from the DMTF WS-Man Standard DSP 226
20:49:45 [Bob]
ack dug
20:50:13 [asir]
s/read mail archive/
20:50:19 [gpilz]
ever one of those use cases can be supported via standard SOAP and WS-Addressing mechanisms
20:50:31 [Ram]
Doug: We provided a proposal to solve the composition problem where there are non-conflicting modes.
20:50:36 [gpilz]
none of them require a unique "Mode" attribute
20:51:10 [Ram]
Doug: This is causing people problems.
20:51:18 [gpilz]
WS-* is based on the orthogonal composition of . . . what's the point?
20:51:26 [gpilz]
nobody is listening
20:51:41 [gpilz]
20:51:46 [Ram]
Wu: Can we use both SOAP headers and Delivery Mode, correct?
20:52:08 [Ram]
Doug: Existing mode extensibility mechanism will probably not work as described in WS-Eventing.
20:52:53 [Ram]
Wu: WS-Eventing allows use of SOAP headers.
20:52:58 [Wu]
20:53:03 [Bob]
ack wu
20:53:06 [Ram]
Wu: in addition to Delivery Mode attribute.
20:53:36 [dug]
yes - other specs (like RM) use soap headers to extend itself
20:53:39 [Ram]
Wu: Question to Yves: Is is OK to use SOAP header in this way to extend the delivery mode semantics.
20:54:42 [Wu]
20:54:50 [asir]
20:54:55 [Ram]
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?
20:55:07 [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.
20:55:13 [Bob]
ack tru
20:55:55 [Ram]
Tom: My concern is that I want WS-Man NOT to have features that are redundant. It will make it more difficult.
20:55:56 [Ram]
Tom: My concern is that I want WS-Man NOT to have features that are redundant. It will make it more difficult.
20:56:52 [Bob]
ack gp
20:56:59 [Ram]
Bob: We can leave the existing mechanism and deprecate it.
20:57:57 [Ram]
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.
20:58:09 [Ram]
Gil: Giving so many options causes interoperability problems.
20:58:40 [Ram]
Gil: Duplicating extensibility points is not a good thing.
20:58:49 [Yves]
interop against extensibility is an unsolvable issue anyway
20:58:53 [Bob]
ack wu
20:59:30 [dug]
Wu: this is a SOAP spec - I don't get it
20:59:41 [Ram]
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.
20:59:44 [gpilz]
WS-Eventing beyond SOAP is outside our charter
20:59:51 [gpilz]
*way* outside our charter
21:00:01 [dug]
we talk about mU headers in other parts of the spec -should we remove those?
21:00:19 [Bob]
ack asir
21:00:20 [gpilz]
Yves: the problem is that, to tell whether or not a message has been extended I need to check 8 different places
21:00:41 [dug]
21:00:59 [Wu]
SOAP extension is allowed and you will see strange things.
21:01:15 [dug]
21:01:21 [Ram]
Asir: We want to have a good reason to change the Delivery Mode mechanism.
21:01:27 [dug]
Been provided - but ignored
21:01:39 [Ram]
Doug: The examples have been provided earlier.
21:02:02 [gpilz]
asir: it doesn't seem likely that there would be any reason good enough to meet your criteria of "sufficient"
21:02:16 [asir]
21:02:38 [Ram]
Bob: At some point, we need to reach consensus.
21:02:54 [Ram]
Bob: otherwise, we want to pull the plug on consensus.
21:03:10 [Zakim]
21:03:15 [Zakim]
21:03:45 [Zakim]
21:03:46 [Zakim]
21:03:46 [Zakim]
21:03:47 [Zakim]
21:03:49 [Zakim]
21:03:50 [Zakim]
21:03:52 [RRSAgent]
I have made the request to generate Yves
21:03:53 [Zakim]
21:03:57 [Zakim]
21:03:59 [Zakim]
WS_WSRA()3:30PM has ended
21:04:00 [Zakim]
Attendees were Bob_Freund, Tom_Rutt, Doug_Davis, Yves, Vikas, Gilbert, li, [Microsoft], Ashok_Malhotra, Asir, JeffM
21:04:11 [TRutt]
TRutt has left #ws-ra
21:04:19 [RRSAgent]
I have made the request to generate Yves
21:04:35 [Zakim]
Zakim has left #ws-ra
21:04:44 [RRSAgent]
I see 3 open action items saved in :
21:04:44 [RRSAgent]
ACTION: Ram to consolidate 6730 proposals for consideration next time [1]
21:04:44 [RRSAgent]
recorded in
21:04:44 [RRSAgent]
ACTION: Ram to prep a consolidated proposal for issue 6730 [2]
21:04:44 [RRSAgent]
recorded in
21:04:44 [RRSAgent]
ACTION: Dug to respod to reviewer on 6725 [3]
21:04:44 [RRSAgent]
recorded in
21:04:47 [Ram]
Bob asks the WG members to review the minutes carefully and make sure everything is properly scribed.
21:04:47 [Ram]
Bob asks the WG members to review the minutes carefully and make sure everything is properly scribed.