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