16:03:32 RRSAgent has joined #ws-ra 16:03:32 logging to http://www.w3.org/2010/05/13-ws-ra-irc 16:03:34 RRSAgent, make logs public 16:03:36 Zakim, this will be WSRA 16:03:37 Meeting: Web Services Resource Access Working Group Teleconference 16:03:37 Date: 13 May 2010 16:03:38 Zakim has joined #ws-ra 16:03:43 Wu has joined #ws-ra 16:06:07 rrsagent, this meeting spans midnight 16:06:30 Ram has joined #ws-ra 16:07:22 Dug has joined #ws-ra 16:08:07 can anyone hear us? 16:08:52 +Yves 16:09:01 Dug, let me try dialing again... did not hear anybody before 16:09:16 Tom_Rutt has joined #ws-ra 16:09:27 +asoldano 16:11:43 Ram: What would the service do when it receives a GetMetadata request that contains a content type that the service does not understand? 16:12:41 Doug to argue our position one more time. 16:12:43 q+ 16:12:53 q- 16:14:11 Dug: To Ram's question, the service will return nothing. 16:14:59 ACTION Dug will respond to Antoine's question on issue 9700 disposition. 16:14:59 Created ACTION-162 - Will respond to Antoine's question on issue 9700 disposition. [on Doug Davis - due 2010-05-20]. 16:15:21 agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0043.html 16:15:45 gpilz has joined #ws-ra 16:16:35 q+ 16:17:57 SCRIBE: gpilz 16:18:19 TOPIC: interop implementation table 16:18:31 Bob: Red Hat is interested in WS-Eventing? 16:19:03 Alession: I need to talk to Mark 16:19:14 Bob: Do you have a date when you will have a complete answer? 16:19:19 Alessio: No. 16:19:38 (misc. back and forth about details of Red Hats interest) 16:20:16 (results recorded in table) 16:20:41 Ram: Paul from WSO2 has participated in this group in the past 16:20:47 ... he may be a potential 16:21:03 ACTION: Bob ping WSO2 about participating in interop testing 16:21:03 Created ACTION-163 - Ping WSO2 about participating in interop testing [on Bob Natale - due 2010-05-20]. 16:22:16 RESOLUTION: minutes from 2010-05-12 approved with modifications as discussed 16:22:37 TOPIC: issue 9610 16:23:02 (misc. recap of where we are) 16:23:13 Wu: we are ok with closing this with no action 16:23:26 ... this is major work and we don't see the value 16:23:40 ... this involves changes in implementation to the Subscription Manager 16:23:53 q+ 16:23:54 ... with little increase in value 16:24:11 q- 16:24:29 Bob: Josh has said that this will meet his needs 16:24:29 ack t 16:24:36 Tom: I think this is an important feature 16:24:40 There was a major telecom disaster in New York city (http://en.wikipedia.org/wiki/33_Thomas_Street ) 16:24:50 ... it will be widely used and should be supported as an optional feature 16:24:59 “ 16:25:01 On September 17, 1991, management failure, power equipment failure, and human error 16:25:03 combined to completely disable AT&T's central office switch at 33 Thomas. As a result, 16:25:04 over 5 million calls were blocked, and Federal Aviation Administration private lines were 16:25:06 also interrupted, disrupting air traffic control to 398 airports serving most of the 16:25:07 northeastern United States. Because the building was designed to be self sufficient, 16:25:09 AT&T had a load shedding agreement with the electric utility, Consolidated Edison, 16:25:10 where they would voluntarily switch from utility power to on-site generators on request. 16:25:12 This was a routine procedure that had been performed successfully in the past, but on this 16:25:13 occasion, it went horribly wrong. After switching power sources, standard procedure was 16:25:15 to check all the equipment power supplies, known as DC plants, for problems. But due to 16:25:16 scheduled training, the check was not performed, and one plant went on battery backup. 16:25:18 The alarms were not detected until it was too late to maintain uninterrupted power 16:25:19 “ 16:25:59 q+ 16:26:05 q+ 16:26:41 Tom: if the Sub Manager can stop a subscription (Unsubscribe) it shouldn't have any problem causing the verify event to be sent 16:27:19 Doug: is it important that the client be able to ask for these verify messages, or is it sufficient for the Event Source to be able to send it and the client can send it by choosing the right filter? 16:27:38 Tom: it's important that the client (event source) be able to determine that the channel is working 16:27:43 q- 16:27:48 ... heartbeat does this, but it is overkill 16:27:54 ack g 16:30:02 (misc. discsussion of "separate request" or "option on GetStatus") 16:30:29 Tom: if we make it an option of GetStatus, we can't re-use the wsa:ActionNotSupported 16:31:19 so what is really needed, a GetStatus on the manager, or verifying that events are going through the event source? 16:32:10 Gil: you don't need a fault, just an indication in GetStatusResponse that the verify notification was sent or not-sent 16:32:58 Gil: suggest we put together a new proposal over lunch 16:33:07 Bob: Wu, would you support this? 16:33:13 Wu: (yes) 16:33:25 Bob: we have a conceptual consensus 16:33:37 TOPIC: 9702 16:33:37 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702 16:33:57 q+ 16:34:55 Ram: (discusses latest proposal in comment #4) 16:35:12 Bob: I have a feeling that the fault will be generated often 16:35:38 q+ 16:35:55 ack d 16:36:02 ack g 16:36:19 Doug: my concern with adding the @exact flag is that this heads us down the slope of adding @min, @max, etc. 16:36:29 ... "hints" mean different things to different people 16:36:42 ... there's no interop around a "hint" 16:37:00 ... if we add back in @exact, that puts us back to where we are today 16:37:10 q+ 16:37:12 q+ 16:37:35 Bob: going back to the original complaint; "how do you compare all these time times?" 16:37:45 ... wasn't that the fundamental problem? 16:38:08 ... wouldn't it make sense to give them a duration expressed as a long int "number of seconds"? 16:38:14 Topic 9610 (verify): It will be an optional attribute in GetStatus. The response from GetStatus indicates whether verify is supported or not. If supported, the verify event will be fired from event source to event sink 16:38:32 ack b 16:39:52 q+ 16:41:15 ack r 16:41:43 Gil: willing to live with making "Expires" server optional if we simplify it by getting rid of @min, @max, etc. 16:42:05 ... don't like making it server optional and keeping complicated things like @exact 16:42:15 Ram: (describes use cases) 16:43:40 ... our experience in implementing Windows shows that the ability to hint is a valuable thing 16:44:26 Wu: yesterday we had 2 options service doesn't support Expires, server supports, no-hint 16:45:15 Ram: (explains proposal in comment #4) 16:45:40 q+ 16:46:20 ack t 16:46:23 The duration data type is used to specify a time interval. I could accept just allowing the duration type for expiry time, with "exact" semantics 16:46:25 The time interval is specified in the following form "PnYnMnDTnHnMnS" where: 16:46:26 P indicates the period (required) 16:46:28 nY indicates the number of years 16:46:29 nM indicates the number of months 16:46:31 nD indicates the number of days 16:46:32 T indicates the start of a time section (required if you are going to specify hours, minutes, or seconds) 16:46:34 nH indicates the number of hours 16:46:35 nM indicates the number of minutes 16:46:37 nS indicates the number of seconds 16:46:38 A profile could specify that the Client use a subset of the above duration units (e.g, days, hours, minutes, seconds), to simplify calculations and comparisons There could be a time unit not supported 16:46:40 exception 16:46:42 This would accommodate event sources with timers but not clocks 16:46:53 q+ 16:48:44 ack w 16:49:09 Wu: thinks we should continue to build on the consensus we established yesterday 16:49:23 ... if you support Expires there should be only one option "match or not" 16:49:38 q+ 16:49:59 ack g 16:51:18 I am wondering about the complexity of this feature ... 16:51:25 Gil: server side optional, no expires==server chooses, specified==exact, specified+@hint=true -> hint 16:51:48 ack d 16:52:00 Doug: um . . . 16:52:09 ... this proposal is a little nicer 16:52:32 ... the entire notion of "hint" is so bizarre 16:52:44 -asoldano 16:52:52 (misc. on the absurdity of a hint) 16:54:14 q+ 16:55:54 ack w 16:56:15 q+ 16:56:35 (continue discussion around use cases proposals) 16:59:13 ack ram 17:03:38 -Yves 17:04:01 q+ 17:04:32 zakim, who is here 17:04:32 Bob, you need to end that query with '?' 17:04:36 zakim, who is here? 17:04:36 On the phone I see [Microsoft] 17:04:38 On IRC I see gpilz, Tom_Rutt, Dug, Ram, Wu, Zakim, RRSAgent, Bob, asoldano, Yves, trackbot 17:05:49 q+ 17:07:45 q+ 17:07:57 MUST just means what the GrantedExpires value is in the response 17:08:19 it doesn't necessarily control the internal adherence to that time 17:15:24 ack r 17:15:30 q- 17:16:17 Dug's original proposal: “Expires is server optional, add a fault for when its not, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault”. 17:16:28 q- 17:16:47 Gil's amendment: Add a @hint attribute to the Expires proposal. 17:20:26 RM: This element, if present, of type xs:duration specifies the RM Source's requested duration for the Sequence. The RM Destination MAY either accept the requested duration or assign a lesser value of its choosing. A value of "PT0S" indicates that the Sequence will never expire. Absence of the element indicates an implied value of "PT0S". 17:21:02 ignore that 17:22:20 Absent == indefinite, present == exact, present + @hint=true == best effort, present/PT0S == indefinite/exact, present/PT0S+@hint=true == indefinite/best-effort 17:23:34 s/hint/bestEffort/g 17:28:20 policy: DateTimeSupported, ExpiresSupported, MaxExpires 17:29:35 add Fault for cases where expires is not supported 17:31:32 asoldano has left #ws-ra 17:33:05 (continued discussion of Expires) 17:35:23 q+ 17:35:51 ack r 17:36:25 +1 to Doug proposal 17:38:49 and this applies to Renew 17:42:46 reoder assertions so they're grouped together 17:42:55 s/reoder/reorder/ 17:45:41 Proposal is jigsawed in the chat room 17:45:55 need a complete proposal to be added as a comment in the bug 17:46:05 lunchtime activity for Dug 17:47:50 proposal in: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702 17:48:41 Bob: any objection to resolving issue with comment #5 (above) 17:49:38 RESOLUTION: 9702 resolved with above proposal 17:49:58 TOPIC: issue 9703 17:53:30 (misc. discussion about the issue and Doug's counter-proposal to Antoine's proposal) 17:56:46
  • li has joined #ws-ra 18:03:02 RESOLUTION: 9703 closed with no action 18:03:21 ACTION: gpilz to respond to Antoine on dispensation of 9703 18:03:21 Created ACTION-164 - Respond to Antoine on dispensation of 9703 [on Gilbert Pilz - due 2010-05-20]. 19:03:18 [Body]/wse:Subscribe/wse:Expires - This OPTIONAL element can be used by the subscriber to indicate the expiration time of the requested subscription. If this element is not present, the implied default expiry time is indefinite (or no expiry). A value of PT0S indicates no expiry. 19:03:39 If the event source does not support wse:Expire element present in a Subscribe request message then a wse:ExpiresNotSupported fault MUST be generated. ... 19:04:19 [Body]/wse:Subscribe/wse:Expires@BestEffort - This OPTIONAL attribute, when present with a value of 'true', indicates that the event source MAY choose an expiry time that best matches the requested expiry time. 19:10:40 How about this: [Body]/wse:Subscribe/wse:Expires@BestEffort - This OPTIONAL attribute, when present with a value of 'true', indicates that the event source SHOULD choose an expiration time that is a best effort of the event source to match the expiration time request. 19:13:37 s/a best effort of the event souce/a best effort/ 19:23:30 wse:Expires@BestEffort - This OPTIONAL attribute, when present with a value of 'true', indicates that the event source SHOULD grant an expiration time that is a best effort of the event source to match the requested expiration time. Default value of this attribute is "false" in which the event source MUST grant the requested expiration time or fault the subscription request. 19:23:38 This OPTIONAL attribute, when present with a value of 'true', 19:23:40 indicates that the event source MUST grant (make a best effort) an 19:23:41 expiration time that matches the specified value. Note, this attribute 19:23:43 is modifying the default behavior of the Expires element 19:23:44 that REQUIRES the event source to exactly match the requested 19:23:46 expiration time. 20:15:51 zakim, who is here? 20:15:51 On the phone I see [Microsoft] 20:15:52 On IRC I see li, gpilz, Tom_Rutt, Dug, Ram, Wu, Zakim, RRSAgent, Bob, Yves, trackbot 20:17:01 TOPIC: 9610 (contd.) 20:17:16 -[Microsoft] 20:17:17 WS_WSRA()11:00AM has ended 20:17:19 Attendees were [Microsoft], asoldano, Yves 20:17:37 (all review proposal 2 - http://www.w3.org/Bugs/Public/attachment.cgi?id=880) 20:40:09 wse:GetStatus/wse:Verify - This OPTIONAL element can be used by the subscriber in its GetStatus request to require the Subscription Manager to check if Notifications can be transmitted from the event source to the event sink. 20:40:23 If event source opts to support the wse:Verify request, it MUST include wse:VerificationInitiated element in its GetStatus response, and it MUST send a single verification event notification, defined in Appendix B, from the event source to the event sink. 20:40:39 When wse:VerificationInitiated element is absent in the GetStatus response, the verification is NOT performed. 20:40:52 Any active filter for the subscription MUST NOT be applied to verification event notification. 20:41:54 s/to require/to request/ 20:42:41 This OPTIONAL element can be used by the subscriber in its GetStatus request to petition the Subscription Manager to check if Notifications can be transmitted from the event source to the event sink. 20:43:14 This OPTIONAL element can be used by the subscriber in its GetStatus request to ask the Subscription Manager to verify if Notifications can be transmitted from the event source to the event sink. 20:44:08 This OPTIONAL element can be used by the subscriber in its GetStatus request to ask the Subscription Manager to verify that Notifications can be transmitted from the event source to the event sink. 20:44:59 If the subscription manager opts to support the wse:Verify request, it MUST include a wse:VerificationInitiated element in its GetStatus response, and it MUST cause the event source to transmit a single verification event notification, defined in Appendix B, from the event source to the event sink. 20:49:25 When wse:VerificationInitiated element is absent in the GetStatus response, the verification is NOT performed. 20:50:02 The absence of this element in a GetStatusResponse indicates that no verification notification was initiated. 20:55:10 The presence of the VerificationInitiated element in a GetStatus response message MUST NOT be used to infer the success or failure of the delivery of the Verification event. 20:55:32 s/GetStatus response/GetStatusResponse/ 20:56:12 The presence of the VerificationInitiated element in a GetStatus response message does not indicate the success or failure of the delivery of the verification notification. 20:57:51 The presence of the VerificationInitiated element in a GetStatus response message does not indicate the success or failure of the delivery of the verification event. 20:58:46 The presence of the VerificationInitiated element in a GetStatus response message does not indicate the success of the verification. 21:08:08 .... it MUST cause the event source to attempt to transmit a notification, containing only a single verification event as defined in Appendix B, from the event source to the event sink. 21:17:53 wse:VerificationInitiated - This element MUST NOT appear in the GetStatusResponse unless the corresponding GetStatus request contained the wse:Verify element. The presence of wse:VerificationIntiated in the GetStatus response indicates the wse:Verify request is honored. The absence of this element in a GetStatusResponse indicates that verification was not initiated. 21:23:14 RESOLUTION: issue 9610 resolved with proposal 5 (http://www.w3.org/Bugs/Public/attachment.cgi?id=883) fix "Verify operation" in first sentence Appendix B; remove "pseudo" from Appendix B 21:25:41 "A value of PT0S indicates is indefinite." ? 21:26:02 Bob: WS-Eventing and WS-Enum must go back to LC 21:26:15 ... we'll do a 3 week last call 21:27:09 ... between now and 5/25/2010 review resolutions to all our issues and make sure the resolutions were properly incorporated 21:27:40 ... if we agree that everything was properly incorporated, we can vote to go to LC again 21:29:42 All: thanks to Microsoft for excellent hosting and yummy food 21:29:53 All: thanks for the well functioning wireless as well 21:31:09 rrsagent, generate minutes 21:31:09 I have made the request to generate http://www.w3.org/2010/05/13-ws-ra-minutes.html Bob 21:33:37 gpilz has left #ws-ra