19:28:36 <RRSAgent> RRSAgent has joined #ws-ra
19:28:36 <RRSAgent> logging to http://www.w3.org/2009/06/02-ws-ra-irc
19:28:38 <trackbot> RRSAgent, make logs public
19:28:38 <Zakim> Zakim has joined #ws-ra
19:28:40 <trackbot> Zakim, this will be WSRA
19:28:40 <Zakim> ok, trackbot, I see WS_WSRA()3:30PM already started
19:28:41 <trackbot> Meeting: Web Services Resource Access Working Group Teleconference
19:28:41 <trackbot> Date: 02 June 2009
19:28:48 <Wu> Wu has joined #ws-ra
19:29:05 <Zakim> +Doug_Davis
19:29:20 <Zakim> +Bob_Freund
19:30:16 <Zakim> +Tom_Rutt
19:30:51 <dug> on a cell so thing could be screwy
19:30:55 <Vikas> Vikas has joined #ws-ra
19:31:00 <Zakim> +Wu_Chou
19:31:23 <Zakim> +Ashok_Malhotra
19:31:39 <Zakim> + +1.571.262.aabb
19:32:03 <Bob> zakim, aabb is Vikas
19:32:03 <Zakim> +Vikas; got it
19:33:06 <Zakim> + +1.408.642.aacc
19:33:22 <Bob> zakim, aacc is Gilbert
19:33:22 <Zakim> +Gilbert; got it
19:33:30 <Ram> Ram has joined #ws-ra
19:33:55 <gpilz> gpilz has joined #ws-ra
19:34:15 <Zakim> +Yves
19:36:34 <Bob> scribe: Ram
19:36:40 <Bob> scribenick: Ram
19:36:40 <Ram> Scribe: Ram (Microsoft)
19:36:50 <asir> asir has joined #ws-ra
19:37:32 <Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0004.html
19:37:45 <dug> q+
19:38:08 <Bob> ack dug
19:38:29 <Bob> ack dug
19:38:50 <Ram> Agenda approved with some changes to issue processing order.
19:39:37 <Ram> The minutes from last meeting has been updated to reflect late attendees.
19:39:46 <dug> http://www.w3.org/2002/ws/ra/9/05/2009-05-19.html
19:40:28 <Bob> http://www.w3.org/2002/ws/ra/9/05/2009-05-26.html
19:40:50 <Ram> No objections. The minutes from May 26th, 2009 has been approved.
19:41:12 <Ram> Administrivia:
19:41:44 <Ram> F2F is next week. Jeff Mischinsky has provide the logistics to WG email list.
19:41:54 <Ram> We will work on key issues and close others as well.
19:42:26 <Ram> Gil: Will look into head count information and do the necessary.
19:43:05 <Zakim> +??P12
19:43:12 <Ram> No further discussion on F2F logistics.
19:43:34 <Bob> zakim, P12 is Snelling
19:43:34 <Zakim> sorry, Bob, I do not recognize a party named 'P12'
19:43:42 <Ram> Bob will post the link to the logistics email to the Administration site for the WG.
19:43:46 <Bob> zakim, ??P12 is Snelling
19:43:46 <Zakim> +Snelling; got it
19:44:13 <gpilz> q+
19:44:19 <Ram> Task team progress:
19:44:19 <Bob> ack gpi
19:44:23 <Ram> 6401.
19:44:26 <Wu> q+
19:44:35 <Ram> Gil has provided an updated proposal.
19:45:00 <Zakim> +JeffM
19:45:19 <dug> +1 to a new closing issue  :-)
19:45:21 <Bob> ack wu
19:45:22 <Ram> Gil: We can discuss this at the end of this call.
19:45:39 <DaveS> DaveS has joined #ws-ra
19:45:46 <Ram> Wu: I have posted an email responding to Gil's proposal. I am not sure if we can discuss this issue this week.
19:46:30 <Ram> Bob: I would like to see progress on 6401 since there are a number of issues behind it.
19:46:46 <asir> q+
19:46:54 <Bob> ack asir
19:46:55 <gpilz> q+
19:47:07 <Ram> Bob: Please make progress on 6401.
19:47:37 <Ram> Dependent issues: 6430, 6661
19:47:48 <Bob> ack gpi
19:48:09 <asir> Probably 6401, 6430 and 6661 are all the same!
19:48:45 <Ram> Gil: There is a lack of clarity on some use cases in Wu's comment.
19:49:06 <Ram> Gil: BP says don't do solicit-response MEP.
19:50:09 <Ram> Next discussion item: Preparation for issues on delivery mode cluster.
19:50:19 <Ram> Geoff: We will be ready by end of this week.
19:50:29 <Ram> Bob: How about T/RT merger?
19:51:07 <Ram> Geoff: Geoff and Doug are working on an assessment/analysis due before end of this week.
19:51:26 <Ram> New issues discussion
19:51:37 <Ram> 6955 (from Geoff Bullen)
19:52:11 <dug> just s/create/manage/   right ?
19:52:20 <Ram> Geoff: The proposal is to change the description for SubscriptionManager.
19:52:51 <Ram> The change is just about s/change/create in the description.
19:53:06 <asir> Clean bowled!
19:53:07 <Ram> The issue is accepted.
19:53:13 <Ram> No objections.
19:53:17 <Ram> Issue resolved.
19:53:27 <Wu> wow, record speed
19:53:35 <Ram> 6956 (from 
19:53:38 <Ram> Geoff)
19:53:50 <dug> bob - I'd like more time on this one
19:54:19 <Ram> Geoff: Ambiguity on what is expected when enumeration context expires and can one tell if the context has expired.
19:54:28 <Ram> Geoff: The state may not be store in the server.
19:54:43 <Ram> Geoff: It is not clear when the enumeration context will expire.
19:55:03 <gpilz> q+
19:55:10 <Ram> Geoff: Section 3.2 needs clarification.
19:56:00 <gpilz> q-
19:57:08 <Ram> Issue accepted. No objections.
19:57:27 <Ram> Bob: We will discuss this further on the mailing list.
19:57:35 <Ram> 6975 (from Gil Pilz)
19:58:26 <Ram> Issue accepted. No objections.
19:58:57 <Ram> 6980 and 6986 are accepted. No objections.
19:59:04 <Ram> 6986 has a proposal.
19:59:58 <Ram> Doug Davis: WS-Eventing does not define a Topic based filter. Change the specification to use XPATH based filter.
20:00:24 <Ram> Refer to Example 4.1 line 43 WS-Eventing.
20:01:10 <li> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table4
20:01:18 <Ram> Also refer to example 5.1.
20:01:37 <li> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table13
20:02:06 <gpilz> q+
20:02:23 <Bob> ack gpil
20:03:24 <Ram> Issue 6986 is resolved.
20:04:05 <Ram> Discussion on issue 6429.
20:04:15 <Wu> Wow, another good progress on 6986
20:05:31 <Ram> Wu: This WSDL is defined by Event Source and used by Event Sink.
20:05:46 <dug> q+
20:06:17 <Bob> ack dug
20:06:49 <gpilz> q+
20:07:32 <Ram> Dug: The challenge is how to get the separate WSDL (if it is made separate).
20:07:45 <Ram> Wu: It is OK to close with issue,
20:08:30 <Ram> Wu: This is dependent of 6401.
20:08:32 <Bob> ack gpi
20:08:44 <Wu> s/Wu/Li
20:08:56 <Zakim> -[Microsoft]
20:09:06 <asir> we are dialing back in
20:09:42 <Zakim> +[Microsoft]
20:10:02 <dug> LOL its all Geoff's fault - minute that!
20:10:05 <Ram> Geoff is button challenged!
20:10:10 <Ram> Apologies accepted :)
20:11:01 <Ram> Bob: We need a new issue here.
20:11:06 <li> +1 gil
20:11:14 <Zakim> -Snelling
20:11:27 <dug> well, it is in the spec as of now
20:11:59 <Zakim> +??P6
20:12:09 <Ram> Bob: This is right now in the WSDL doc.
20:12:35 <DaveS> Snelling back
20:12:46 <dug> zakim who is making noise?
20:12:52 <Ram> ACTION ITEM: Gil to file a new issue (relating to 6429) to move the wrapped events and put in a separate WSDL.
20:12:52 <trackbot> Sorry, couldn't find user - ITEM
20:13:07 <li> thanks gil
20:13:39 <Ram> Discussion Issue 6916.
20:13:48 <Ram> Dug: I have provided a proposal today.
20:15:12 <Geoff> q+
20:15:24 <Bob> ack geo
20:15:53 <gpilz> q+
20:15:55 <dug> q+
20:16:41 <li> q+
20:16:55 <Bob> ack gpi
20:17:04 <Ram> Gil: Generating a fault is misleading.
20:17:34 <dug> s/Generating/kind of generating/
20:17:58 <Ram> Gil: Generating provides no guarantee what the endpoint does with the generated fault. It is essentially unverifiable.
20:18:13 <Ram> Gil: No need to transmit the generated fault.
20:18:20 <Bob> ack dug
20:18:35 <DaveS> q+
20:18:38 <Bob> ack li
20:19:05 <Ram> Li: If the server generates a fault but does not transmit a fault what does the client see?
20:19:32 <Ram> Bob: The service may not transmit a fault if it does not trust the client.
20:19:52 <gpilz> or if there is no mechanism for transmitting the fault
20:20:07 <Zakim> -JeffM
20:20:07 <gpilz> e.g. one-way operation with the HTTP back-channel closed
20:20:17 <dug> +1 any kind of fault isn't ok with security folks - even letting them know that something went wrong is too much info
20:20:18 <Bob> ack dave
20:21:14 <dug> q+
20:21:20 <Bob> ack dug
20:21:24 <Ram> Dave: What we are trying to say is if a fault is transmitted then a specific fault MUST be transmitted.
20:21:41 <gpilz> q+
20:21:57 <Bob> ack gpi
20:22:35 <Ram> Gil: MUST generate a specific fault is sufficient. This is independent of the decision to transmit.
20:23:15 <DaveS> q+
20:23:39 <dug> anyone else hearing static?
20:23:46 <dug> mixing voices?
20:23:49 <Ram> Yes, there is static.
20:23:51 <dug> oh good, not just me
20:23:54 <DaveS> q-
20:24:03 <li> too much statics
20:24:06 <gpilz> that's not static
20:24:09 <Ram> Can Dave type in his comment?
20:24:20 <gpilz> that's dropped packets
20:24:32 <dug> LOL
20:24:36 <Bob> ack dave
20:24:40 <DaveS> I support unifying the specs.
20:24:49 <li> must transmit the fault :-)
20:24:52 <asir> :-)
20:25:16 <DaveS> I might raise a separate issue tom clean up the ambiguity around "generate" vresus "transmit"
20:25:49 <Geoff> q+
20:25:54 <DaveS> q+
20:26:04 <Bob> ack geo
20:26:15 <Ram> Geoff: There are a couple of other specific cases as well.
20:26:40 <dug> q+
20:26:54 <Bob> q?
20:27:19 <Ram> In WS-Enumeration section 3.2
20:27:26 <Bob> ack dave
20:27:35 <Ram> what do we do with this? Does this need any clarification?
20:27:51 <Bob> ack dug
20:29:31 <Ram> There is also ambiguity relating to 6956 in the WS-Enumeration specification.
20:29:48 <Ram> Geoff: I take back my comment. I am fine.
20:30:10 <Ram> 6916 is RESOLVED with latest proposal. No objections.
20:30:38 <Ram> Issue 6712 discussion.
20:30:54 <DaveS> q+
20:31:04 <Geoff> q+
20:31:09 <Bob> ack dave
20:31:37 <gpilz> q+
20:32:03 <Ram> Dave: The implementation and presentation layer need some close coupling to process this.
20:32:13 <dug> q+
20:32:23 <gpilz> q-
20:33:01 <Bob> ack geo
20:33:50 <gpilz> q+
20:34:16 <Ram> Geoff: I gave two examples. It seems to me that a wrapper does the same thing and has the same problems.
20:34:53 <Ram> Geoff: The choice between what is a literal value and what is an instruction is complicated.
20:35:30 <Geoff> that is correct
20:35:57 <Ram> Bob: HTTP PUT operation does not have any expectation on the content/payload. Why do we need to define the content?
20:36:43 <Ram> Dug: To me why this is different is because WS-Transfer talks about two things: One is XML representation and the other is the instruction.
20:37:01 <Ram> Dug: If the WS-Transfer were to remove this distinction, then we don't need this.
20:37:28 <asir> modeled after HTTP
20:37:48 <Ram> Dug: WS-Transfer does NOT say that it is modeled after HTTP.
20:37:56 <Bob> ack dug
20:38:07 <Ram> Bob: It may be in the charter though.
20:38:11 <DaveS> Interesting note: The iPhone text correction function corrects 'WSRA" to "WARS" :-)
20:38:21 <Geoff> q+
20:39:20 <asir> ws-transfer does not talk about Doug's use case
20:40:14 <Ram> Dug: There is nothing in the WS-Transfer spec that GET must return a wrapper response.
20:41:03 <Bob> acl gpi
20:41:09 <Bob> ack gpi
20:42:28 <Ram> Gil: How can I do anything useful if cannot interpret the XML?\
20:43:00 <Ram> Gil: How do I interpret the blob?
20:43:06 <dug> Ram - he's saying the opposite - he's saying there _are_ cases where you don't want to interpret it
20:44:03 <dug> q+
20:44:57 <Ram> Gil: We should stay away from defining what the instruction is without any interpretation. We want the service to do the interpreration.
20:45:14 <Bob> ack geo
20:46:09 <Ram> Geoff: It is a very specific use case. A DB client and DB service. The DB service takes a BLOB and stuffs it in the DB.
20:46:41 <Ram> Geoff: There is a tight coupling between the DB client and DB service.
20:47:21 <DaveS> q+
20:47:37 <Ram> Geoff: By creating a dialect we are forcing a service to interpret it.
20:48:33 <Ram> Geoff: How do I know if my BLOB is going to be interpreted or not?
20:48:48 <Ram> Geoff: How does the client know what the service expects?
20:49:03 <asir> just like HTTP!
20:49:31 <Ram> Geoff: The service is the one that defines the XML representation / instruction.
20:49:40 <asir> Server is in control!
20:50:24 <Bob> ack dug
20:50:54 <Ram> Dug: I am asking for a mechanism for the service to distinguish what the client is sending in.
20:51:04 <Bob> ack dave
20:51:21 <gpilz> q+
20:51:57 <Ram> Dave: We can find a compromise.
20:51:58 <dug> dave - my default was NO ATTRIBUTE
20:51:59 <asir> this is nothing to do with existing impl
20:52:24 <Ram> Dave: Define a default that is closer to current mechanism.
20:52:50 <Bob> ack gpi
20:53:02 <Ram> Bob: Let us pause on this issue and move on to 6401.
20:53:37 <Geoff> q+
20:54:44 <Ram> Gil: Once i have a dialect, i can know what nofication types are supported.
20:56:14 <Ram> Gil: By adverstising notification types, it is easy to filter based on notification types.
20:56:35 <Wu> q+
20:56:37 <Bob> ack geo
20:57:05 <Ram> Geoff: Your proposal has a strong reliance on MEX. Maybe you could placate my concern.
20:57:33 <Ram> Geoff: Do I need to have a running service to issue a MEX call against?
20:58:48 <Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0002.html
21:01:21 <li> composition vs. geneative approach
21:02:25 <Zakim> -Gilbert
21:02:26 <Zakim> -Wu_Chou
21:02:27 <Zakim> -Doug_Davis
21:02:27 <Zakim> -[Microsoft]
21:02:28 <Zakim> -??P6
21:02:28 <Zakim> -Yves
21:02:30 <Zakim> -Bob_Freund
21:02:30 <Zakim> -Tom_Rutt
21:02:32 <Zakim> -Vikas
21:02:32 <RRSAgent> I'm logging. I don't understand 'draft minute', Yves.  Try /msg RRSAgent help
21:02:33 <li> wu: composition would support generative
21:02:34 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/02-ws-ra-minutes.html Yves
21:02:35 <Zakim> -Ashok_Malhotra
21:02:45 <Zakim> - +0125660aaaa
21:02:46 <Zakim> WS_WSRA()3:30PM has ended
21:02:47 <Zakim> Attendees were +0125660aaaa, [Microsoft], Doug_Davis, Bob_Freund, Tom_Rutt, Wu_Chou, Ashok_Malhotra, +1.571.262.aabb, Vikas, +1.408.642.aacc, Gilbert, Yves, Snelling, JeffM
21:02:48 <DaveS> DaveS has left #ws-ra
21:05:37 <TomRutt> TomRutt has left #ws-ra
21:06:39 <gpilz> gpilz has left #ws-ra