19:28:17 <RRSAgent> RRSAgent has joined #ws-ra
19:28:17 <RRSAgent> logging to http://www.w3.org/2010/06/01-ws-ra-irc
19:28:19 <trackbot> RRSAgent, make logs public
19:28:19 <Zakim> Zakim has joined #ws-ra
19:28:21 <trackbot> Zakim, this will be WSRA
19:28:21 <Zakim> ok, trackbot, I see WS_WSRA()3:30PM already started
19:28:22 <trackbot> Meeting: Web Services Resource Access Working Group Teleconference
19:28:22 <trackbot> Date: 01 June 2010
19:28:44 <Wu> Wu has joined #ws-ra
19:29:01 <Zakim> +Bob_Freund
19:29:44 <Zakim> +Tom_Rutt
19:30:12 <Zakim> +Wu_Chou
19:30:32 <dug> q+  to add a new topic to the agenda
19:30:38 <Zakim> +Gilbert_Pilz
19:30:42 <Katy> Katy has joined #ws-ra
19:30:58 <asoldano> asoldano has joined #ws-ra
19:31:09 <Zakim> +Yves
19:31:16 <MartinC> MartinC has joined #ws-ra
19:31:21 <Zakim> + +1.408.970.aaaa
19:31:31 <Zakim> +asoldano
19:31:45 <Zakim> +[Microsoft]
19:31:50 <Katy> Katy has joined #ws-ra
19:32:18 <Fred_Maciel> Fred_Maciel has joined #ws-ra
19:32:27 <Ram> Ram has joined #ws-ra
19:32:37 <Bob> agenda:  http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jun/0000.html
19:32:39 <Zakim> + +03531803aabb
19:32:43 <Zakim> + +1.646.361.aacc
19:32:57 <Zakim> + +0196281aadd
19:33:03 <MartinC> Zakim, _0353 is MartinC
19:33:03 <Zakim> sorry, MartinC, I do not recognize a party named '_0353'
19:33:20 <MartinC> zakim, +0353 is MartinC
19:33:20 <Zakim> +MartinC; got it
19:33:23 <gpilz> gpilz has joined #ws-ra
19:33:54 <Zakim> Not knowing who is chairing or who scribed recently, I propose Wu_Chou
19:34:33 <dug> scribe: Dug
19:34:39 <dug> scribenick: Dug
19:34:54 <dug> Topic: agenda
19:34:56 <Bob> ack dug
19:34:56 <Zakim> dug, you wanted to add a new topic to the agenda
19:35:16 <Bob> agenda+ Policy param on verify
19:35:37 <dug> agenda is approved with addition 
19:35:52 <dug> Topic: approving minutes from May 13
19:35:58 <dug> approved w/o
19:36:10 <dug> Topic: new issues
19:36:22 <dug> 9871: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9781
19:36:26 <dug> oops
19:36:28 <dug> 9781:  http://www.w3.org/Bugs/Public/show_bug.cgi?id=9781
19:36:42 <dug> Wu: describes issue
19:37:28 <Zakim> + +1.800.456.aaee
19:37:30 <dug> Min supported should be subscribe/unsubscribe
19:37:38 <dug> s/Min/Wu: Min/
19:37:54 <dug> ... will make ws-eventing light weight and useful
19:38:10 <dug> ... mandatory features should be the common denominator 
19:38:36 <dug> ... can't profile out required features
19:39:13 <dug> resolution: new issue accepted for consideration
19:39:33 <dug> Topic: reviewer comments
19:39:48 <dug> q+
19:39:55 <Bob> ack dug
19:39:55 <Katy> q+
19:39:58 <dug> q-
19:40:01 <Bob> ack katy
19:40:31 <dug> Topic: back to 9781
19:40:43 <dug> Katy: what if they tried to use Renew? would WSA fault be returned?
19:41:24 <dug> Wu: WSA would cover it and we'd add a policy assertion
19:41:59 <dug> q+
19:42:10 <dug> Katy: why were they made mandatory?
19:43:45 <dug> Wu: explains why he thinks they should be required
19:44:00 <dug> ... makes impl harder to do timers - assuming expires is supported
19:44:37 <Bob> ack dug
19:45:46 <Zakim> - +1.646.361.aacc
19:46:47 <dug> Dug: feel strongly that GetStatus should remain - w/o it we have no way to know if a subscription is still alive
19:47:06 <dug> ... Renew, a little less strong but still leaning towards it since its cheap to support
19:47:36 <dug> Rick Landau joined the call - from dmtf wsman wg
19:48:00 <dug> continue on mailing list
19:48:21 <dug> Topic: WS-I BP WSDL issue
19:48:48 <dug> Gil: WSDL is now in its own section
19:48:55 <dug> ... we can update our ref to section 5
19:49:22 <dug> Bob: ETA on publication?
19:50:00 <dug> ... need a board approved draft
19:50:35 <dug> ... not completed profile, just board approved draft, to go to CR
19:50:41 <dug> ... for REC we need a completed profile
19:50:54 <Ram> q+
19:51:32 <Bob> ack ram
19:53:21 <dug> Ram: how will we ref it?
19:53:40 <dug> Bob: TBD
19:53:59 <dug> Topic: 9609
19:54:02 <dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9609
19:54:07 <Zakim> +Ashok_Malhotra
19:55:05 <dug> Rick: talks about the requirement
19:55:26 <dug> ... permit enumResponse to include the results of the first pull operation
19:55:40 <dug> ... w/o optimization then just the enumContext is returned
19:55:53 <dug> Bob: during f2f we talked about this
19:56:01 <dug> ... during Pull you specify a lot of options
19:56:10 <dug> ... Enumerate() would want to have the same options
19:56:24 <dug> ... so why not just merge Pull and Enumerate into one op
19:56:33 <dug> ... fold Enum into Pull
19:56:57 <Tom_Rutt> q+
19:57:03 <dug> Rick: would have done it the other way but same end result
19:57:25 <Bob> ack tom
19:57:57 <dug> Tom: reaction was to the title "small result sets", just an optimization which might mean everything, but could just mean the first set
19:58:11 <dug> ... didn't catch that it was for both, large and small result sets
19:58:35 <dug> Rick: trying to reduce the network traffic by one MEP
19:58:41 <dug> Bob: reaction?
19:58:45 <dug> q+
19:59:28 <gpilz> q+
19:59:37 <dug> Tom: pull has lots of parameters - adding this might not be that bad
19:59:46 <Bob> ack dug
19:59:58 <Ram> q+
20:00:02 <Bob> ack gp
20:00:14 <dug> Dug: would prefer this to dup'ing Pull parameters into the Enumeate
20:00:42 <dug> Gil: we talked about complexity around dup'ing Enum params/faults.... in Enumerate
20:01:24 <dug> ... the other way, getting rid of enumerate(), we lose the ability to setup many enums w/o actually pulling anything
20:01:51 <dug> ... we lose this bit of functionality
20:01:59 <dug> Bob: couldn't you just pull for zero items
20:02:12 <dug> Gil: I recall people saying "blah"   :-)
20:02:25 <dug> ... no strong advocate for the usecase
20:02:32 <dug> ... during the f2f
20:02:50 <dug> ... I'm concerned about the tie to CIM's notion of polymorphism 
20:02:58 <dug> q+
20:03:29 <dug> Rick: understood - that's why they changed the focus to be on just reducing network traffic
20:03:47 <dug> ... network traffic has been a bit issue for impls
20:04:13 <Tom_Rutt> q+
20:04:44 <dug> Bob: if we proposed Pull+implicit Enum, would that meet your needs?
20:04:49 <dug> Rick: yes
20:04:52 <Bob> ack ram
20:05:02 <dug> Ram: would prefer to have two independent verbs
20:05:15 <dug> ... there are things you do during Enum vs Pull
20:05:21 <dug> ... but see the need for the optimization
20:05:46 <dug> ... proposal from Dell is preferred
20:05:58 <Bob> ack dug
20:06:16 <dug> Dug: Gil can you elaborate on the polymorphism thing?
20:06:32 <dug> Gil: don't worry about it
20:06:45 <Bob> ack tom
20:06:48 <dug> ... just focus on network traffic
20:06:59 <gpilz> where is Rick's latest proposal?
20:07:03 <dug> q+
20:07:16 <dug> Tom: how often will the params change?
20:07:39 <dug> ... not a big change
20:07:45 <Bob> ack dug
20:09:38 <dug> Dug: duping everything across Enum and Pull is going to be ugly and a pain for extensions who will need to do the same thing
20:09:47 <dug> Bob: u ok with a Pull of zero items?
20:09:48 <dug> Dug: yes
20:09:52 <dug> Bob: Ram, you?
20:10:33 <dug> Ram: need to examine the practical implications of both
20:11:04 <dug> ... no strong opposition at this time, but no final position
20:11:11 <dug> Bob: who will write up a proposal?
20:11:36 <Tom_Rutt> q
20:11:37 <Tom_Rutt> =
20:11:40 <Tom_Rutt> q
20:11:42 <Tom_Rutt> =
20:11:46 <Tom_Rutt> q+
20:11:55 <dug> Ram: I like Dell's proposal
20:11:57 <Bob> ack tom
20:12:21 <dug> Tom: adding params from Pull into Enum might not be that bad
20:12:35 <gpilz> q+
20:12:40 <gpilz> q-
20:13:18 <dug> Bob: are you willing to promote Dell's proposal?
20:13:23 <dug> s/are/Ram are/
20:14:02 <Tom_Rutt> I think that if every pull has the same size parameters, it would make sense to put the params on the enum request, allowing the first pull and subsequent pulls to use those size params.  
20:15:18 <Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0053.html
20:15:44 <Ram> Ram has joined #ws-ra
20:16:07 <dug> Ram: ok with Dell to come back with a more detailed proposal
20:16:19 <Tom_Rutt> q+
20:16:46 <dug> Tom: adding the size params to the enum would work
20:16:51 <Ram> q+
20:16:56 <Bob> ack tom
20:17:28 <dug> Rick: mentions this in the doc (link above)
20:17:44 <dug> Ram: can work with Rick on a cleaner proposal
20:17:51 <dug> q+
20:18:01 <dug> Bob: need a directional decision
20:18:10 <dug> ... first
20:18:32 <Bob> ack ram
20:18:32 <Bob> ack dug
20:18:46 <Tom_Rutt> q+
20:19:05 <gpilz> uploaded Rick's expanded use case and motiviation discussion: http://www.w3.org/Bugs/Public/attachment.cgi?id=886&action=edit
20:19:20 <Ram> q+
20:19:24 <dug> Dug: what's the concern with a Pull that just asks for zero items?
20:19:26 <Bob> ack tom
20:20:19 <dug> Tom: confused about the proposal
20:20:42 <Bob> ack ram
20:20:49 <dug> Dug: get rid of enum and move the feature under Pull
20:21:02 <dug> Ram: wsa:Action is enough to know what to do
20:21:17 <dug> ... preference is to keep it separate 
20:21:36 <dug> ... if WG wants to merge into a pull I'll need more time
20:21:53 <dug> Bob: what about a Pull child to Enum?
20:22:00 <dug> ... basically batching
20:22:37 <Tom_Rutt> q+
20:22:48 <dug> ... all children of Pull can appear under Enumerate/Pull
20:22:55 <Bob> ack tom
20:23:06 <dug> Tom: pull child to enum might work
20:23:08 <gpilz> q+
20:23:17 <Bob> ack gp
20:23:26 <dug> Gil: interesting idea but it might not be that easy
20:23:34 <Tom_Rutt> q+
20:23:36 <dug> ... what about maxTime?
20:24:06 <dug> ... would the enumContext still be created during the waiting time?
20:24:14 <dug> ... probably
20:24:22 <dug> Bob: same issue if we merged pull and enum
20:24:37 <dug> Gil: yes applies to all cases
20:24:57 <dug> ... this is the complexity we were talking about
20:25:24 <Zakim> +vvarma
20:25:31 <Bob> ack tom
20:25:36 <dug> Bob: there is no escaping the complexity  :-)
20:25:38 <Vikas> Vikas has joined #ws-ra
20:25:47 <dug> Tom: leaning now towards CWNA
20:26:05 <dug> ... keeping the http connection open isn't that expensive
20:26:55 <dug> ... Rick, why do you see this as an important optimization when the data on the enum is small and you can just keep the connection open?
20:27:15 <dug> Rick: our experience is that the # of turn-arounds is the problem
20:27:29 <dug> ... not keeping the connections open makes it worse, but we do keep them open today
20:27:35 <dug> ... its the turn-around that's the issue
20:27:44 <dug> ... its double in the current model
20:28:02 <dug> ... its not the tear-down of the tcp/ip connection
20:28:16 <dug> Bob:  a) add pull param to enum
20:28:29 <dug> ... b) add enum flag to pull  (remove enum)
20:28:36 <dug> ... c) add Pull child to Enum
20:29:29 <dug> ... c - implies Pull child is a full Pull - like batching.  a - means we dup the params across the two ops
20:29:38 <dug> Tom: what's the fault model?
20:29:58 <dug> Bob: both enum and pull faults could occur
20:30:13 <dug> Gil: would a pull fault still allow the enum to be created?
20:30:39 <dug> Rick: fault would mean no context is created
20:30:54 <dug> q+
20:31:03 <Bob> ack dug
20:31:08 <dug> d) CWNA
20:31:41 <Zakim> -asoldano
20:32:18 <dug> Dug: no, yes, yes, yes
20:32:30 <dug> Hitachi: abs, abs, abs, abs
20:32:35 <gpilz> Oracle (in order): d, c, b, a
20:32:53 <dug> Oracle: yes, yes, yes, yes
20:33:10 <dug> MSFT: yes, no, yes, no
20:33:22 <dug> SAG: abs, abs, abs, abs
20:33:26 <Tom_Rutt> no no yes yes
20:33:30 <dug> Avaya: abs, abs, abs, abs
20:33:31 <asoldano> sorry, did confusion with the mobile, but it's abs for all
20:33:36 <dug> w3c: yes, no, yes, yes
20:33:46 <dug> Fuj: no, no, yes, yes
20:33:50 <dug> s/Dug/IBM
20:33:58 <dug> Redhat: seems to have dropped
20:34:29 <dug> a and b go away - no objection
20:34:42 <Zakim> +asoldano
20:35:11 <dug> Redhat: abs, abs, abs, abs
20:35:26 <dug> c - add a Pull child to enum
20:35:33 <dug> Bob: who will write up the proposal?
20:36:04 <dug> Ram: Rick would you be willing to work with me on this?
20:36:15 <dug> Bob: Rick, will this satisfying your needs?
20:36:24 <dug> Rick: not sure how this works from a soap point of view
20:36:39 <dug> action: Ram to write-up a proposal with Rick's help for Enum optimization issue
20:36:40 <trackbot> Created ACTION-165 - Write-up a proposal with Rick's help for Enum optimization issue [on Ram Jeyaraman - due 2010-06-08].
20:36:42 <dug> q+
20:37:08 <dug> q-
20:37:17 <dug> Topic: 9613
20:37:20 <dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613
20:38:07 <dug> q
20:38:09 <dug> q+
20:38:18 <dug> Rick: no way to know if a subscription is persistent
20:38:55 <dug> Bob: been involved in a ton of discussions about persistence - how long? how is it done?
20:39:17 <dug> ... across failure of persistence mechanisms
20:39:27 <dug> ... is it impl specific ?
20:40:19 <dug> ... subscription lasts until an unsubscribe, times out, any other reason
20:40:23 <dug> q-
20:40:34 <dug> ... can we really define what "persistent" means?
20:42:01 <dug> Rick: many different levels of paranoia 
20:42:10 <dug> none - I want 10  :-)
20:42:33 <Bob> 11
20:43:19 <MartinC> q+
20:44:26 <Wu> q+
20:44:33 <dug> Rick: (discusses various levels of "certainty of operation")
20:45:23 <dug> ... lowest level of persistent subscription
20:45:45 <Bob> ack martin
20:45:56 <Bob> how would we test this?
20:46:31 <dug> Martin: doesn't the expires mean that the subscription will live that long?
20:46:34 <Bob> ack wu
20:46:59 <dug> Wu: seems like its coming from not having a heartbeat 
20:47:17 <dug> ... if we can provide a heartbeat would that address your concern
20:47:18 <dug> ?
20:47:49 <dug> Rick: heartbeat adds to it
20:48:05 <dug> Wu: its a keep alive signal
20:48:28 <dug> Rick: keep alive addresses the integrity of the link - persistent doesn't cover that
20:48:59 <dug> Wu: persistence is a very huge statement
20:49:03 <dug> ... very large promise
20:49:17 <dug> Bob: event queue might persist but subscription could be forgotten
20:49:53 <dug> ... how might we test this?
20:49:54 <MartinC> im concerned about inventing yet another set of mechanisms that already exist and can be layered e.g. reliable messaging
20:49:58 <Tom_Rutt> q+
20:50:05 <Bob> ack tom
20:50:24 <dug> Tom: the SubscriptionEnd msgs + keep alive/heartbeat seems like it should be enough
20:50:32 <dug> Bob: confirm CWNA?
20:50:48 <dug> ... any objection to cwna?
20:51:00 <dug> resolution: close with no action
20:51:07 <dug> resolve: close with no action
20:51:22 <dug> ... impls are free to specify their own level of persistence
20:51:46 <Tom_Rutt> q+
20:51:48 <dug> Topic: 9610
20:51:50 <dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610
20:52:35 <dug> Bob: things happening at regular intervals causes network issues
20:52:50 <Bob> ack tom
20:53:07 <dug> Tom: heartbeats are not always sent, just when there's no events sent
20:53:28 <dug> ... not against a heartbeat (keep alive) feature
20:53:40 <Wu> q+
20:54:00 <dug> Bob: couldn't we just have the impl define a heartbeat event that people can subscribe to?
20:54:08 <dug> Tom: its an auto-kick/verify
20:54:33 <dug> q+
20:55:10 <dug> Bob: network issues are a real concern
20:55:44 <dug> Rick: did my reply msg get sent to the wsra list?
20:55:54 <dug> ... its the same a http/tcp keep-alive
20:56:26 <dug> ... its not send a regular intervals - its only when nothing is sent for a subscription for a period of time
20:56:32 <dug> s/send a/send at/
20:56:48 <dug> Bob: who is the caring party? subscriber or subscription?
20:57:05 <dug> ... if its the subscriber then they can do a GetStatus/Verify
20:57:09 <Bob> ack wu
20:57:33 <dug> Wu: keep-alive is a possible solution
20:57:38 <Zakim> - +1.408.970.aaaa
20:57:51 <dug> ... keep-alive could reduce the MEPs
20:58:06 <Bob> ack dug
20:58:45 <dug> Dug: keeping a timer per subscription sounds expensive
20:59:07 <dug> Topic: VerifySupported assertion
20:59:46 <Tom_Rutt> q+
21:00:02 <Zakim> -MartinC
21:00:02 <MartinC> MartinC has left #ws-ra
21:00:09 <Bob> ack tom
21:00:13 <dug> tom: yes add it
21:00:27 <dug> no objection to adding the missing assertion parameter
21:00:51 <asoldano> bye
21:00:52 <dug> Adjourned 
21:00:53 <Zakim> -Tom_Rutt
21:00:54 <Zakim> -Wu_Chou
21:00:54 <Zakim> -vvarma
21:00:56 <Zakim> -[Microsoft]
21:00:56 <Zakim> -Ashok_Malhotra
21:00:57 <Zakim> - +1.800.456.aaee
21:00:57 <Zakim> -Yves
21:00:58 <Zakim> -Bob_Freund
21:01:00 <Zakim> -asoldano
21:01:01 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/01-ws-ra-minutes.html Yves
21:01:02 <Zakim> -Gilbert_Pilz
21:01:04 <Zakim> -Doug_Davis
21:03:47 <Zakim> - +0196281aadd
21:03:48 <Zakim> WS_WSRA()3:30PM has ended
21:03:50 <Zakim> Attendees were Doug_Davis, Bob_Freund, Tom_Rutt, Wu_Chou, Gilbert_Pilz, Yves, +1.408.970.aaaa, asoldano, [Microsoft], +03531803aabb, +1.646.361.aacc, +0196281aadd, MartinC,
21:03:53 <Zakim> ... +1.800.456.aaee, Ashok_Malhotra, vvarma
21:28:37 <gpilz> gpilz has left #ws-ra