00:02:15 gil: as event sink, may need more detail, e.g. SOAP 1.1, 1.2, RPC, ... 00:04:17 gil: static wsdl is hard to determine the what binding is. 00:04:42 Yeves: binding maybe specified in subscription time to make things easy 00:05:46 bob: 6429 will take further discussion to the list. 00:06:14 bob: 6430 00:07:55 ??P5 is a trouble maker 00:08:12 see, told you 00:08:22 +q 00:08:25 li: propose an attribute to indicate event source 00:08:29 +q 00:08:54 li: we should consider W3C Semantic Annotation for WSDL and XML Schema 00:09:19 q+ 00:09:56 ack dug 00:11:57 dug: I am wondering if this should be at portType level, operation level, etc. 00:12:30 ack gpil 00:13:28 gil: need to do homework and think of a competing proposal using policy 00:16:40 ack asir 00:17:21 prasad: this may relate to bp issue 00:18:33 asir: some question of attribute 00:19:04 li: it allows to you to subscribe port, not source 00:19:23 asir: it will help to make the context know. 00:20:27 li: in ecma-348, need to indicate in SOAP header 00:20:50 Geoff: what is the mapping in wsdl and what you subscribe 00:21:12 li: this is another submitted issue for ws-e 00:22:01 asir: some background of the issue is very helpful 00:23:46 asir: policy assertion apply to shared behavour and event source may not 00:23:55 action: Li in email to the public list, describe the background and implications to 6430 more fully 00:24:13 rrsagent, pointer 00:24:13 See http://www.w3.org/2009/01/16-ws-ra-irc#T00-24-13 00:24:31 Geoff: to link the issue with 6425 which is another half will be helpful 00:25:52 bob: 6431 is next 00:26:21 li: propose add pause/resume operation to ws-e 00:27:26 rrsagent, pointer 00:27:26 See http://www.w3.org/2009/01/16-ws-ra-irc#T00-27-26 00:27:38 li: it can reduce ws-e overhead in subscribe/resubcribe 00:27:54 gil: seem a good idea, like to see more detail 00:28:43 bob: events will be qued or pause event delivery 00:29:32 li: open to implementation/application at this moment 00:30:36 gil: maybe define pause or queue at start. maybe this is an implementation choice 00:30:54 q+ 00:31:28 bob: it may add a lot of complexity. there is any additional cost beyond subscribe/unscribe 00:32:11 q+ 00:32:58 What if you pause and forget (to resume) forevere? 00:33:20 s/vere/ever/ 00:33:22 li: pause is very common in business case 00:34:07 q+ 00:34:08 ack asir 00:34:29 asir: need to consider cr phase 00:34:31 questions about possible cost of a subscription or delivery reminds me of the safeness of WS-Transfer:Get... 00:34:54 Yves - can you elaborate? 00:35:18 ack wu 00:35:23 if you retreive something using WS-T:Get and something goes wrong, is it safe to re-issue the request or not? 00:35:56 ie: is WS-T:Get used in case of payment to retreive information (where you don't want to do twice ;) ) 00:35:58 safe 00:36:01 ack prasad 00:36:29 we might clarify that in WS-T then 00:36:37 I'll open an issue ;) 00:36:42 wu: we can confine pause as a short-hand of subscribe/unsubscribe then subscribe, which semantics are defined in ws-e 00:36:43 ok 00:38:34 - +1.908.696.aaaa 00:38:39 are you saying that T.get() will change the fact that a payment happened? 00:39:50 If we introduce pause / resumeetc, semantics need to be simple. No pooling of events until resume etc. Pause will make you lose events until resume also. Otherwise huge overhead on the event-source side and what if the pause is never resumed. There need to be timeout semantics also 00:39:59 no, I just wonder if people are tying T.Get and payment (as it may lead to double charging someone if T.Get implies you can safely re-issue the request if something fail, like power failure) 00:40:32 bob: 6398 issue 00:41:43 q+ 00:43:41 ack geo 00:43:47 dug: looking atthe impact on ws-rt 00:45:59 Geoff: we need extensibility. ws-rt spec is on extending ws-t. 00:46:36 Geoff: by making changes suggested, this relation broken 00:47:10 Geoff: Thus, this is a significant change to ws-rt 00:47:51 asir: needs to think more 00:48:00 dug: I missed that relation 00:48:27 dug: one way to solve it is to ask ws-rt to use the same wrapper 00:48:47 asir: this is significant change and like to see detail 00:48:54 gpilz has left #ws-ra 00:49:21 q+ 00:49:32 dug: like to know if this wg is o.k. to that geneal direction 00:50:07 ack asir 00:50:57 asir: need to know more if this is reasonable 00:53:56 action: Dug Take proposal for 6398 to the next level of detail including extension to include impact on WS-RT, including deleteRequest (getting us to 8 operations in T) 00:55:18 s/T)/T) and MEX 00:55:39 q+ 00:55:54 ack greg 00:57:02 -gregcarp 00:57:03 rrsagent, generate minutes 00:57:03 I have made the request to generate http://www.w3.org/2009/01/16-ws-ra-minutes.html Bob 00:57:30 see you next Tuesday 00:59:09 -??P5 00:59:10 WS_WSRA()11:00AM has ended 00:59:11 Attendees were +1.908.696.aaaa, gregcarp