IRC log of ws-ra on 2010-05-11

Timestamps are in UTC.

15:56:44 [RRSAgent]
RRSAgent has joined #ws-ra
15:56:44 [RRSAgent]
logging to http://www.w3.org/2010/05/11-ws-ra-irc
15:56:46 [trackbot]
RRSAgent, make logs public
15:56:46 [Zakim]
Zakim has joined #ws-ra
15:56:48 [trackbot]
Zakim, this will be WSRA
15:56:48 [Zakim]
ok, trackbot, I see WS_WSRA()11:00AM already started
15:56:49 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
15:56:49 [trackbot]
Date: 11 May 2010
16:00:56 [Vikas]
Vikas has joined #ws-ra
16:01:56 [Zakim]
+ +1.703.860.aaaa
16:02:00 [Zakim]
+ +39.331.574.aabb
16:02:08 [asoldano]
Zakim, aabb is asoldano
16:02:12 [Zakim]
+asoldano; got it
16:03:17 [Zakim]
-asoldano
16:03:24 [Dug]
Dug has joined #ws-ra
16:04:03 [Dug]
Yves, you on the sys-req email dist list for w3c?
16:04:42 [Tom_Rutt]
Tom_Rutt has joined #ws-ra
16:04:52 [Vikas]
Zakim, aaaa is vvarma
16:04:52 [Zakim]
+vvarma; got it
16:05:00 [Dug]
anyone on the phone?
16:05:15 [asoldano]
Dug, dialing in again..
16:05:31 [Vikas]
Dug, I am on phone.
16:05:41 [Bob]
can anyone hear us on the phone?
16:05:43 [Zakim]
+asoldano
16:05:44 [Dug]
can you hear us?
16:06:06 [asoldano]
Dug, no, I can't, can just hear Vikas
16:06:45 [Dug]
can you hear bob now?
16:06:48 [asoldano]
yep
16:07:30 [Ram]
scribenick Ram
16:07:48 [Ram]
Ram will do May 11, Tom will May 12, and Gil will May 13
16:08:27 [Ram]
The above note is for minute takers for the meetings.
16:08:28 [Bob]
agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0018.html
16:08:47 [Zakim]
+ +1.617.324.aacc
16:09:09 [Dug]
Yves, you on the sys-req email dist list for w3c?
16:09:12 [Yves]
no
16:09:19 [Wu]
Wu has joined #ws-ra
16:09:26 [Ram]
The agenda is approved. No objections.
16:09:34 [Ram]
Minutes of May 4th approved. No objections.
16:09:45 [Ram]
New issues
16:11:10 [Ram]
All issues are accepted. No objections.
16:11:31 [Zakim]
-asoldano
16:11:37 [Zakim]
+asoldano
16:11:50 [Ram]
Discussion on definition of independent implementations
16:11:57 [Bob]
"the implementations must be independent and not derived from a common ancestor that implements the specification under test."
16:12:09 [Ram]
q+
16:12:28 [Dug]
Yves - do you have any of the sysreq guys on IM or something you can ping quickly? I've lost access to cvs and would like to get it fixed quickly so I can edit the specs.
16:13:41 [Yves]
dug: I saw that ted was taking care of this
16:14:11 [Ram]
"the implementations of the specifications features must be independent and not derived from a common ancestor that implements the specification under test."
16:14:14 [Dug]
sort of - he "fixed" it so now I can't access it from my old machine either :-)
16:14:30 [Ram]
Correction: "the implementations of the specification features must be independent and not derived from a common ancestor that implements the specification under test."
16:14:46 [Ram]
Correction: "the implementation of the specification features must be independent and not derived from a common ancestor that implements the specification under test."
16:14:52 [Ram]
q+
16:15:03 [Bob]
ack ram
16:15:15 [Yves]
dug, the key I see in there is the one you sent...
16:15:48 [Dug]
I need my old key in there too. Not sure why the new key isn't working for the new machine but I'll worry about that later. Right now I'm still on my old machine and I need access for the f2f.
16:17:31 [Ram]
Ram: Should we ask for advice from W3C Team on this matter?
16:17:47 [Ram]
Yves: There is nothing wrong with the WG deciding on the nature of the implementations.
16:19:00 [Ram]
No objections to Bob's proposal as amended by Ram: "the implementation of the specification features must be independent and not derived from a common ancestor that implements the specification under test."
16:19:20 [Ram]
The above will be this WG's guideline for implementation of the specifications.
16:19:31 [Ram]
Issue 9570
16:19:54 [Dug]
sent - I hope that's the right one - for some reason I always have trouble with this stuff
16:21:52 [Yves]
me dug, can you try now?
16:22:49 [gpilz]
gpilz has joined #ws-ra
16:23:00 [Ram]
Gil describes the proposal.
16:23:08 [Dug]
yves - nope still fails
16:23:23 [Ram]
Issue 9570 is RESOLVED.
16:23:29 [Ram]
Issue 9569
16:23:43 [Ram]
Gil: Proposal needs more work. Will get this done by afternoon.
16:23:51 [Ram]
Bob: We will defer this until tomorrow.
16:24:13 [Ram]
Issue 9607
16:25:24 [Ram]
Gil describes the proposal.
16:25:26 [Dug]
sent
16:26:12 [Dug]
q+
16:27:28 [Bob]
ack dug
16:27:34 [Bob]
q+ Tom
16:27:48 [Ram]
Dug: I have many concerns about this issue.
16:28:16 [Ram]
Dug: Allowing updates to change EPR seems poor architectural design.
16:28:53 [Ram]
Dug: The client has to communicate any changes to the EPR (cascade effect); this proposal does not address this.
16:28:55 [Vikas]
Vikas has joined #ws-ra
16:29:30 [Ram]
Dug: This notion of the server being able to tell the client "use a different EPR" is not a Transfer specific problem.
16:30:02 [Ram]
Dug: We could think of a seperate specification to work on this, but this is out of scope for this WG.
16:30:06 [Tom_Rutt]
If a transfer put induced state change on a resource results it a change of its epr, then that same epr might change due to state changes due to other stimuli associated with the resource.
16:30:08 [Tom_Rutt]
In such an environment, I feel strongly that using an event report notification "state change induced EPR change" would be a better solution.
16:30:12 [Bob]
ack tom
16:31:00 [Ram]
Tom: WS-Man WG can address this issue specific to their domain.
16:31:05 [Ram]
Tom: Don't like this proposal.
16:32:28 [Ram]
Bob: EPR itself contains extension point where other domain specific information could be inserted.
16:32:38 [Ram]
Dug: EPR is more static than a cookie.
16:33:06 [Ram]
Bob: Any objections to close with no action?
16:33:30 [Ram]
Issue 9607 CLOSED WITH NO ACTION.
16:35:16 [Ram]
Bob: Record the response to WS-Man in the bug and respond on the public mailing list.
16:36:05 [Ram]
ACTION Tom to send a response to the WS-Man WG about the disposition of issue 9607.
16:36:05 [trackbot]
Created ACTION-148 - Send a response to the WS-Man WG about the disposition of issue 9607. [on Tom Rutt - due 2010-05-18].
16:38:30 [Ashok_Malhotra]
Ashok_Malhotra has joined #ws-ra
16:39:14 [Ram]
Issue 9567
16:41:42 [Ram]
GIl describes the proposal.
16:42:49 [Ram]
Wu: Can i ask for another hour so Li has a chance to check?
16:42:52 [Ram]
Bob: Yes.
16:43:02 [Ram]
Issue 9610
16:44:07 [Ram]
Gil describes the proposal from WS-Man.
16:44:17 [Bob]
q?
16:45:29 [Wu]
q+
16:45:35 [Ram]
Gil describes some enhancements suggested by WS-Man about how to negotiate the heartbeat.
16:45:53 [Ram]
Bob: Some systems may want heartbeat and others may not.
16:47:36 [Bob]
ack wu
16:48:14 [Ram]
Wu: There is many wrinkles when you dig deeper about heart beats. The frequency of the heart beat need to be specified. The event source may become overloaded with heart beat pseudo events.
16:48:42 [Ram]
Wu: If the client cannot be reached, what should the event source do? Delete subscription, etc?
16:48:55 [Ram]
Wu: It is a whole new protocol.
16:49:04 [gpilz]
q+
16:49:14 [Ram]
Wu: This should be outside the general WS-Eventing spec.
16:49:39 [Ram]
Wu: Event subscribers could use GetStatus to probe the event source. Using a heart beat is out of scope.
16:50:14 [Bob]
ack gpi
16:50:28 [Ram]
Gil: About the delivery frequency of heart beats, we need a mechanism to negotiate that.
16:50:44 [Bob]
q+
16:51:04 [Ram]
Gil: I think using the existing mechanisms such as subscription expiration we can work it out.
16:52:07 [Dug]
q+
16:52:15 [Bob]
q-
16:52:17 [Ram]
Gil: I don't see why we cannot define heart beats and leave the details to individual implementations.
16:52:21 [Wu]
q+
16:52:33 [Dug]
q-
16:52:39 [Ram]
Bob: It occurs to me that heart beats are inherently less scalable in terms of network capacity.
16:53:13 [gpilz]
q+
16:53:16 [Ram]
Bob: Don't know how big the bag of clients are who receive heart beat notifications.
16:53:28 [Ram]
Bob: A pull mechanism such as GetStatus is better.
16:53:48 [Bob]
ack gpi
16:53:49 [Ram]
Bob: A client can automatically back off, etc.
16:54:12 [Ram]
Gil: Your point about load is well taken. But an event source is not required to support heart beats.
16:54:42 [Ram]
Gil: The WS-Man folks use heart beat only in low client counts.
16:55:54 [Ram]
Gil: Hence, network load is not a concern. The GetStatus may not actually work since the entity who receives the heart beat notification and the entity that sends GetStatus may be different.
16:56:20 [Ram]
Bob: I prefer an event ping instead of a heart beat.
16:56:36 [Ram]
Bob: That is sufficient to handle the use case.
16:57:18 [Ram]
Bob: Using a fault to negotiate a capability is not a reliable way to do things; since faults need not be transmitted.
16:57:41 [Bob]
q?
16:57:45 [Bob]
ack wu
16:57:56 [Ram]
Wu: I second Bob's opinion. Heart beat can be issue of capacity and waste of bandwidth.
16:59:04 [Ram]
Wu: If a subscriber subscribes to multiple subscriptions, the question arises whether the source sends single or multiple heart beats.
16:59:16 [Ram]
Gil: The heart beat is on a per subscription basis.
17:00:13 [Ram]
Wu: That means a subscriber gets many heart beats from the same event source?
17:00:36 [Ram]
Gil: Yes. But I don't see a concern.
17:01:12 [Ram]
Bob: Would a single heart beat such a ping satisfy?
17:01:21 [Ram]
Gil: Need to explore this with WS-Man.
17:04:34 [Ram]
Dug: What is the difference between GetStatus and synthetic ping from the event sink to the Subscription Manager to send a heart beat?
17:04:43 [Ram]
Gil explains on white board.
17:07:54 [Dug]
q+
17:09:16 [gpilz]
"Verify" is a good name for this operation
17:09:44 [Bob]
ack dug
17:10:09 [Ram]
Dug: Is GetStatus is synchronous the reason why it cannot be used?
17:10:58 [Ram]
Gil: No, the event source and sink may be disconnected.
17:12:03 [Ram]
Dug: Event source is a conceptual object.
17:13:46 [Yves]
if the heartbeat is not received, you also don't know if it was not generated, or not transmitted, or lost in an outgoing proxy somewhere
17:13:53 [Yves]
(in the heartbeat case)
17:14:01 [Bob]
+1 to Yves
17:14:24 [Ram]
Dug: I like to better understand what sort of problems/use cases this addresses. I am having trouble distinguishing between asynchronous replyTo on a GetStatus seems sufficient.
17:15:12 [Ram]
q+
17:15:52 [Bob]
ack ram
17:16:15 [Wu]
q+
17:17:19 [Bob]
ack wu
17:17:26 [Ram]
Ram echoes the same sentiment as Dug.
17:17:34 [Ram]
Wu: I agree with Ram and Doug.
17:19:58 [Ram]
There is some debate about why can't GetStatus/GetStatusResponse serve the same function of a "Verify" ping message followed by a Verify response from event source.
17:20:42 [Ram]
Break until 10:30AM PT.
17:21:46 [Zakim]
-asoldano
17:23:00 [Zakim]
-Yves
17:27:26 [Katy]
Katy has joined #ws-ra
17:30:31 [Zakim]
+ +0196281aadd
17:34:17 [Zakim]
+asoldano
17:35:21 [Bob]
Bob has joined #ws-ra
17:35:24 [Ram]
Meeting about to resume
17:36:16 [Ram]
Issue 9671
17:36:18 [li]
li has joined #ws-ra
17:36:53 [Zakim]
+ +1.908.696.aaee
17:37:14 [li]
aaee is li
17:37:24 [li]
zakim, asee is li
17:37:24 [Zakim]
sorry, li, I do not recognize a party named 'asee'
17:37:37 [li]
zakim, aaee is li
17:37:37 [Zakim]
+li; got it
17:38:41 [Ram]
Katy explains the proposal.
17:42:20 [Dug]
http://www.w3.org/Bugs/Public/attachment.cgi?id=868
17:42:20 [Dug]
proposal
17:43:28 [Ram]
q+
17:44:52 [gpilz]
q+
17:46:14 [Bob]
ack ram
17:46:58 [Bob]
ack gpi
17:47:43 [Ram]
Ram points to a minor editorial correction.
17:48:07 [Dug]
there are other editorial things too :-)
17:48:13 [Dug]
but they're minor
17:50:06 [Dug]
q+
17:50:12 [Ram]
Gil: If the metadata is updated to say for example WS-MakeConnection is supported, it creates metadata that is out of sync with the service.
17:50:50 [Ram]
Gil: Is this a configuration mechanism?
17:51:05 [Ram]
It is a remote configuration mechanism, yes.
17:52:05 [Ram]
Katy: It is no different from an administrative mechanism to update an endpoint's configuration metadata.
17:52:13 [Bob]
ack dug
17:54:13 [gpilz]
q+
17:54:46 [Ram]
Dug: There are two types of metadata out there. Metadata that is manipulable by the service and that which cannot be manipulable by the service's configuration. That is where remote configuration comes to being.
17:54:51 [Bob]
ack gp
17:55:20 [Ram]
Gil: There are two faces to metadata.
17:55:37 [Ram]
Gil: One which the service project outward for all/otheres to see.
17:56:18 [Ram]
Gil: Another is about configuration metadata.
17:57:16 [Ram]
Gil: WS-Policy is not well suited for configuration metadata.
17:58:05 [Ram]
Katy: I don't fully agree.
18:03:28 [Ram]
Bob: This seems to be reiteration of 6411 i suppose.
18:06:27 [Ram]
No objections. Issue 9671 RESOLVED as proposed.
18:07:43 [Ram]
Back to Issue 9610.
18:08:04 [Dug]
q+
18:08:33 [Ram]
ACTION Gil to come back with a proposal for this issue before end of this F2F
18:08:33 [trackbot]
Sorry, couldn't find user - Gil
18:08:43 [Bob]
ack dug
18:08:50 [Ram]
ACTION gpilz to come back with a proposal for this issue before end of this F2F
18:08:50 [trackbot]
Created ACTION-149 - Come back with a proposal for this issue before end of this F2F [on Gilbert Pilz - due 2010-05-18].
18:10:21 [Ram]
Dug: The proposal we are thinking about to resolve this issue is quite radical. It is not clear if WS-Man WG would agree to this radical approach. We can close this issue with no action and ask the WS-Man WG to consider the radical approach; if there is an uptake we can reopen the issue.
18:12:24 [gpilz]
Katy, are you still there?
18:13:06 [gpilz]
I just realized that I don't know what fault an endpoint should generate if it simply doesn't support PutMetadata
18:13:14 [Ram]
Dug: We need to explain the reasons for closing with no action.
18:14:47 [Ram]
Gil: If we close with no action, then we may loose the option to re-open it later since we may go on to CR soon.
18:15:47 [Ram]
Dug: Why don't we wait until tomorrow when WS-Man gets a chance to discuss?
18:16:37 [Ram]
There is general consensus.
18:17:48 [Ram]
Back to issue 9567
18:18:21 [Ram]
Issue 9567 RESOLVED with version 4 of proposal.
18:18:43 [Ram]
Issue 9569
18:19:30 [Bob]
rrsagent, this meeting spans midnight
18:20:01 [Ram]
Issue 9569 RESOLVED with proposal 1.
18:20:41 [Ram]
Issue 9611
18:21:32 [Ram]
WS-Man folks thought that others may want the batched delivery mechanism.
18:22:15 [Wu]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9611
18:24:22 [Ram]
Li: The batched delivery mode is covered by the wrapped delivery format already.
18:24:22 [gpilz]
q+
18:25:10 [Zakim]
- +0196281aadd
18:26:51 [Wu]
q+
18:27:53 [Ram]
Wu: WS-Eventing as it is already meets the requirements of the issue.
18:28:33 [Bob]
ack wu
18:30:15 [Ram]
Wu: In short, WS-Eventing alreadys supports the batching mode.
18:30:41 [Bob]
ack gp
18:30:52 [Ram]
Dug: Clarification: The wrapped delivery does not necessary support this since this has only a single action URI.
18:32:17 [Wu]
q+
18:32:19 [Ram]
Gil: The strawman proposal is underspecified. If this WG is interested in batched mode, we can work on it. Otherwise, why spend the effort?
18:33:32 [Dug]
q+
18:33:42 [Bob]
ack wu
18:34:31 [Dug]
q-
18:34:32 [Bob]
q+
18:34:39 [Ram]
The current model in WS-Man does not work adequately. It only says you can batching without exceeding a certain number or seconds. That is a weak constraint.
18:35:04 [gpilz]
q+
18:35:19 [Ram]
Wu: If we want to do this, we need to do this in a way this works.
18:36:48 [Bob]
ack bob
18:36:51 [Ram]
Bob: First off, i view batching as a significant overhead for resource-constrained environments. It may be best to leave it to specific domains to do this right.
18:36:54 [Bob]
ack gpi
18:36:55 [li]
+1 bob
18:37:31 [Dug]
q+
18:37:31 [Ram]
Gil: I like to address the underlying use case without taking on an obligation to take it on.
18:38:01 [Ram]
Gil: This may be a pre-mature optimization.
18:38:03 [Bob]
ack dug
18:38:31 [Wu]
q+
18:39:29 [Ram]
Dug: I am torn on this one. It is a nice optimization for example like in WS-Notification. At the same time, when batching was attempted (with SOAP messages, etc), there are issues such as transactionality, etc. It really is a can of worms. It is best to leave it to the domain experts to deal with this.
18:39:39 [Bob]
ack wu
18:39:44 [Ram]
Wu: I second Dug's comment.
18:39:47 [gpilz]
q+
18:40:28 [Bob]
ack gpi
18:41:23 [Tom_Rutt]
q+
18:41:42 [Bob]
ack tom
18:41:44 [Ram]
Gil: There are ordering issues with batching as well.
18:42:01 [Ram]
Tom: How does one do filtering with batching?
18:42:36 [Ram]
Dug: Specification already says that filtering happens before formatting.
18:42:50 [Ram]
Bob: Any one in favor of proposal?
18:43:11 [Ram]
Bob: Any objections to close with no action?
18:43:13 [Ram]
Wu agrees.
18:43:31 [Ram]
Wu moves to close with no action.
18:43:54 [Ram]
No objections.
18:44:22 [Ram]
Issue 9611 CLOSED WITH NO ACTION.
18:44:36 [Ram]
ACTION Wu to prepare a response for 9611.
18:44:36 [trackbot]
Created ACTION-150 - Prepare a response for 9611. [on wu chou - due 2010-05-18].
18:44:53 [Ram]
Issue 9568
18:45:29 [Bob]
http://www.w3.org/Bugs/Public/attachment.cgi?id=870
18:46:50 [Zakim]
-asoldano
18:47:54 [Ram]
Issue 9568 resolved as proposed.
18:47:58 [Ram]
in version 2.
18:48:31 [Ram]
Lunch break until 12:50pm PT.
18:49:09 [Ram]
The conference call will restart @ 12:50pm PT.
18:49:26 [Zakim]
-[Microsoft]
19:01:18 [Zakim]
-vvarma
19:07:03 [Zakim]
-li
19:07:05 [Zakim]
WS_WSRA()11:00AM has ended
19:07:08 [Zakim]
Attendees were [Microsoft], +1.703.860.aaaa, +39.331.574.aabb, asoldano, vvarma, +1.617.324.aacc, Yves, +0196281aadd, +1.908.696.aaee, li
19:36:29 [Fred]
Fred has joined #ws-ra
19:36:53 [Zakim]
WS_WSRA()11:00AM has now started
19:37:00 [Zakim]
+ +1.408.970.aaaa
19:38:27 [Zakim]
- +1.408.970.aaaa
19:38:28 [Zakim]
WS_WSRA()11:00AM has ended
19:38:28 [Zakim]
Attendees were +1.408.970.aaaa
19:58:12 [Zakim]
WS_WSRA()11:00AM has now started
19:58:19 [Zakim]
+[Microsoft]
19:58:22 [Bob]
we are re-starting
19:58:40 [Ram]
Issue 9612
20:01:33 [Yves]
me zakim, call yves-617
20:01:41 [Zakim]
-[Microsoft]
20:01:41 [Zakim]
+[Microsoft]
20:01:42 [Zakim]
+Yves
20:01:49 [Yves]
s/me zakim, call yves-617//
20:01:50 [Ram]
Bob: Why would we need to add XPath Level 2 dialect?
20:02:13 [Ram]
Gil: XPath Level 2 = XPath Level 1 + extra operators
20:03:13 [Zakim]
+li
20:04:07 [Ram]
Gil: WS-Man wants to see if the XPath dialects have generic applicability.
20:07:18 [Ram]
Bob: It is not clear how WS-RA can determine if a particular subset of XPath is acceptable to other WGs?
20:07:38 [Ram]
Bob: Different communities are going to want different level of subsetting of XPath.
20:09:36 [Ram]
Bob: Should WS-RA be the one defining all the various flavors of XPath?
20:10:02 [Yves]
as long as we have a way for people to define and use their own flavor, we should only define what we need (and do only minor stuff to help others)
20:10:07 [Ram]
Gil: Yeah. It is sufficient to define the base framework that allows use of various dialect.
20:11:14 [Ram]
Bob: Feel a bit uncomfortable about taking on something that we do not care that much.
20:11:47 [Ram]
Dug: Since we do not have people clamoring for this, don't see a need to do this.
20:12:35 [Dug]
q+
20:12:50 [Ram]
Bob: We should define Dialect URI for XPath 2.0.
20:12:52 [Bob]
ack dug
20:13:55 [Ram]
Bob: Since it is a W3C Recommendation.
20:14:38 [Ram]
Dug: We should do a separate issue.
20:14:41 [Ram]
Bob will open a new issue.
20:15:11 [Ram]
Is there an alternate solution?
20:15:39 [Ram]
Dug: If we were to send XPath Level 1 to WS-Security WG, then we send XPath Level 2 to them as well.
20:16:39 [Ram]
Bob: I hear a consensus to close with no action.
20:17:30 [Ram]
No objections. Issue 9612
20:17:54 [Ram]
Issue 9612 CLOSED WITH NO ACTION.
20:19:13 [Ram]
Issue 9558
20:20:35 [Ram]
Tom: If we take on developing XPath levels / profiles, then we will have to be open to taking on many different such level and profiles. Are we ready for that?
20:20:50 [Ram]
Bob: Do we care about XPath Level 1 in WS-Fragment?
20:21:42 [Ram]
No one expresses a strong interest.
20:22:19 [Ram]
Bob: Any objections to removing XPath Level 1 from WS-Fragment?
20:22:53 [Ram]
Dug: This means that the serialization rules in the specification need to retained.
20:24:05 [Ram]
Bob: We can respond to XML Security WG that they need to define their own XPath Level.
20:25:04 [Ram]
Dug: Is the response that WS-RA is getting out of the business of defining XPath dialects?
20:25:15 [Dug]
s/Dug/Gil/
20:25:52 [Dug]
All: yes that's the answer
20:26:18 [Ram]
Proposal: Remove XPath level 1 from WS-Fragment AND respond to XML Security WG that WS-RA is getting out of the business of defining XPath levels.
20:26:38 [Ram]
ACTION Bob to respond to Frederick / XML Security WG.
20:26:38 [trackbot]
Created ACTION-151 - Respond to Frederick / XML Security WG. [on Bob Natale - due 2010-05-18].
20:27:06 [Ram]
ACTION gpilz to respond to WS-Man about WS-RA's position on XPath level support.
20:27:06 [trackbot]
Created ACTION-152 - Respond to WS-Man about WS-RA's position on XPath level support. [on Gilbert Pilz - due 2010-05-18].
20:27:23 [Ram]
Issue 9558 CLOSED WITH NO ACTION.
20:28:30 [Ram]
Issue 9613
20:30:27 [Ram]
Gil: WS-Man manages a farm of little devices that go through power cycles, etc. It is difficult to keep it going if the subscriptions are transient.
20:30:45 [Ram]
Gil: Hence, they have this feature called persistent subscriptions.
20:31:28 [Wu]
q+
20:31:40 [Bob]
ack wu
20:32:02 [Ram]
Wu: The intention is good, but there are issues here. We think QoS is a complex mechanism and should be a separate description.
20:32:15 [Ram]
Wu: What does it mean to say a subscription is persistent.
20:32:22 [Ram]
Wu: What about caching, etc?
20:34:31 [Ram]
Gil: There is no notion of caching. WS-Man has a different model for dropped events.
20:35:16 [Ram]
Dug: If we define a persistent flag, we need to define all the various aspects such as caching, etc.
20:35:52 [Ram]
Wu: This is a feature that qualifies for a separate QoS spec. Hence, close with no action.
20:36:28 [Ram]
Bob, Dug: WS-Eventing events can be persistent as it is today; it is not precluded.
20:36:39 [Tom_Rutt]
q+
20:36:52 [Ram]
Gil: Nothing in our specs says delivery is guranteed, it is best effort.
20:37:38 [Ram]
Gil: It would be useful to know which devices in a farm can and cannot support persistent subscriptions.
20:38:46 [Dug]
q+
20:39:01 [Bob]
ack tom
20:40:53 [Tom_Rutt]
How would one of these small devices behave if there was an EndTo EPR in the subscribe request. would the have enough "smarts" to be able to send the SubscriptionEnd message before it goes down, or at its reboot?
20:40:55 [Tom_Rutt]
So would this small device also not be able to accept EndTo EPRs in the subscription?
20:41:04 [Wu]
q+
20:41:17 [Ram]
Gil: There are a number of QoS in WS-Man specs such as delivery mode (push with ack), etc. It is domain specific.
20:41:24 [Bob]
ack dug
20:41:34 [Ram]
Dug: I am sensing that we are heading towards close with no action.
20:42:20 [Ram]
Dug: Subscription expiry and persistence have some relation.
20:44:41 [gpilz]
A subscription can become invalid for any reason including:
20:44:42 [gpilz]
Subscription deleted (via Unsubscribe)
20:44:42 [gpilz]
Subscription expired
20:44:42 [gpilz]
Subscription ended (via SubscriptionEnd)In addition, the Event Source/Subscription Manager MAY cancel a subscription at any time, as necessary.
20:47:48 [Bob]
ack wu
20:48:00 [Ram]
Gil: Section 4 of WS-Eventing clarifies this that the source makes a best effort.
20:48:54 [Tom_Rutt]
q+
20:50:50 [Ram]
q+
20:51:09 [Bob]
ack tom
20:51:10 [Tom_Rutt]
The management workstation should be able to determine the kind of kit is is dealing with, and have a table in its own state to know whether the event source has persistence of subscriptions. They seem to be asking that the subscribe operation exchage, itself, have a way for the management station to obtain this knowledge.
20:52:48 [Ram]
q-
20:53:37 [Ram]
Gil: There is out-of-band knowledge that is necessary here.
20:58:24 [Ram]
Tom: An event source that does not have the ability for persistence better not accept a subscription with an EndTo.
21:01:14 [Ram]
Tom: If the systems goes down abruptly, is it out of scope of the spec.
21:01:40 [Wu]
q+
21:03:10 [Ram]
Gil: We need some clarity about abortive shutdown case.
21:03:27 [Ram]
Dug: The spec already says best effort.
21:04:37 [Bob]
ack wu
21:07:28 [Ram]
Proposed response to WS-Man WG: Persistence is a difficult topic. After due consideration, we have decided that this is domain specific and outside the scope of the WS-RA work. However, your issue has caused us to add "if possible" to the description of SubscriptionEnd message.
21:07:58 [Ram]
The above clarification would help deal with abortive shutdown cases.
21:10:28 [Dug]
q+
21:10:41 [Bob]
ack dug
21:12:11 [Dug]
... via a SubscriptionEnd message if an EndTo was present in the Subscribe message.
21:12:18 [Ram]
Dug: In addition, add the above.
21:12:26 [Dug]
to end of 2nd para in section 4
21:13:30 [Dug]
bye !
21:13:33 [Ram]
See you.
21:13:34 [Zakim]
-Yves
21:14:19 [Ram]
Issue 9613 RESOLVED as proposed above.
21:17:28 [Ram]
Issue 9655
21:17:42 [Ram]
Issue 9655 CLOSED WITH NO ACTION.
21:18:45 [Ram]
Issue 9608
21:22:02 [Ram]
Gil explains the proposal.
21:23:15 [Ram]
Dug: What if the enumeration count is dynamic?
21:23:56 [Ram]
Dug: I am just worried that it is an estimate and there are no guarantees; but if there are no guarantees how is it useful?
21:24:09 [Ram]
Dug: It seems too specific to a particular use case.
21:24:56 [Ram]
Bob: What if EnumerateResponse has an optional element that indicates total count at that point in time.
21:28:06 [Ram]
Dug: Calculating size could be expensive.
21:30:27 [Ram]
Bob: What shall we do?
21:30:54 [Ram]
Gil: Close with no action.
21:31:59 [Ram]
Gil: This seems domain specific.
21:32:20 [Ram]
Gil: The addition of this extra information does not seem useful in the general case.
21:33:07 [Ram]
Issue 9608 CLOSED WITH NO ACTION.
21:33:23 [Ram]
ACTION Dug to write up response to 9608.
21:33:23 [trackbot]
Created ACTION-153 - Write up response to 9608. [on Doug Davis - due 2010-05-18].
21:34:09 [Ram]
Issue 9609
21:34:30 [Ram]
Gil: This is an optimization to avoid round-trip.
21:36:17 [gpilz]
q+
21:36:39 [Ram]
Dug: I am worried about the implication of this.
21:36:43 [li]
bye
21:36:47 [Dug]
bye
21:36:53 [Zakim]
-li
21:37:24 [Zakim]
-[Microsoft]
21:37:25 [Zakim]
WS_WSRA()11:00AM has ended
21:37:25 [Zakim]
Attendees were [Microsoft], Yves, li
21:38:14 [Ram]
Gil: Agrees.
21:39:12 [Ram]
Bob: Why not simply do a poll?
21:39:23 [Dug]
s/poll/pull/
21:42:26 [Ram]
Dug: Why not model this as a Transfer resource?
21:45:30 [Dug]
s/Dug/Gil/
21:49:04 [Ram]
Ram: We need to determine if this has generic usefulness.
21:49:35 [Ram]
Ram: We need to make sure before collapsing Enumerate and Pull if implementations do special initializations during Enumerate.
21:52:17 [Ram]
ACTION gpilz to work on a proposal for 9608
21:52:17 [trackbot]
Created ACTION-154 - Work on a proposal for 9608 [on Gilbert Pilz - due 2010-05-18].
21:59:21 [Ram]
Ram: Since there doesn't seem any interest in this optimization, suggest close this with no action.
21:59:51 [Ram]
Ram: Since there does not seem a generic applicability of this optimization.
21:59:54 [Tom_Rutt]
rationale: the cost in terms of spec and implementation complexity outweighs the potential benefits of saving a round trip of network exchange for a minority of use cases
22:05:02 [Ram]
No objections.
22:05:16 [Ram]
Issue 9609 CLOSED WITH NO ACTION.
22:08:23 [Ram]
Issue 9699
22:08:36 [Dug]
"All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR."
22:10:13 [Dug]
"All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR, and be sent with WS-Addressing 1.0 engaged."
22:11:20 [gpilz]
"All messages defined by this specification MUST be sent with WS-Addressing 1.0 engaged.
22:12:26 [gpilz]
"All messages defined by this specification MUST be sent with WS-Addressing 1.0 engaged and sent to a Web service that is addressable by an EPR."
22:12:38 [Dug]
All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR (see [WS-Addressing]).
22:14:53 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specification and sent to a Web service thatis addressable by an EPR.
22:15:13 [gpilz]
"All messages defined by this specification MUST be sent with the headers required by the WS-Addressing 1.0 specification"
22:15:38 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service thatis addressable by an EPR.
22:16:01 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR.
22:16:40 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR ( see [WS-Address]).
22:16:53 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR ( see [WS-Addressing]).
22:18:47 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specification and be sent to a Web service that is addressable by an EPR ( see [WS-Addressing 1.0 SOAP Binding]).
22:21:08 [Dug]
All messages defined by this specification MUST conform to the WS-Addressing specifications and be sent to a Web service that is addressable by an EPR ( see [WS-Addressing]).
22:22:32 [Ram]
Issue 9699 is RESOLVED as proposed with the latest proposal above.
22:23:48 [Ram]
ACTION Dug to respond to comment submitter on 9699.
22:23:48 [trackbot]
Created ACTION-155 - Respond to comment submitter on 9699. [on Doug Davis - due 2010-05-18].
22:25:11 [Ram]
Issue 9676
22:30:06 [Dug]
<!-- Notification WSDL can go here - see Appendix x.y -->
22:30:07 [Dug]
<!-- EventDescription Data can go here - see Appenfix x.y -->
22:38:39 [Dug]
If the Event Source advertises Notification WSDL then it MUST appear as a child of the FormatName element. and do this for EVD data too.
22:47:31 [Ram]
Issue 9676 RESOLVED as proposed above.
22:53:20 [Ram]
Issue 9675
22:54:19 [Ram]
ACTION Dug to add examples for Notification WSDL.
22:54:19 [trackbot]
Created ACTION-156 - Add examples for Notification WSDL. [on Doug Davis - due 2010-05-18].
22:57:47 [Bob]
recessed
22:57:58 [Bob]
rrsagent, generate minutes
22:57:58 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/05/11-ws-ra-minutes.html Bob
23:02:29 [Bob]
http://mattsrotisserie.com/menus.html
23:04:19 [wu]
wu has joined #ws-ra
23:26:56 [Bob]
?
23:30:06 [Dug]
slap Bob
23:30:21 [Dug]
?
23:30:22 [Dug]
?help
23:56:57 [Zakim]
Zakim has left #ws-ra
02:11:54 [gpilz]
gpilz has left #ws-ra