IRC log of ws-ra on 2009-06-02

Timestamps are in UTC.

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