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

Timestamps are in UTC.

15:36:18 [RRSAgent]
RRSAgent has joined #ws-ra
15:36:18 [RRSAgent]
logging to
15:36:20 [trackbot]
RRSAgent, make logs public
15:36:20 [Zakim]
Zakim has joined #ws-ra
15:36:22 [trackbot]
Zakim, this will be WSRA
15:36:22 [Zakim]
ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start 6 minutes ago
15:36:23 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
15:36:23 [trackbot]
Date: 11 June 2009
15:42:08 [Paul]
Paul has joined #ws-ra
15:46:53 [Bob]
Bob has joined #ws-ra
15:47:11 [Bob]
trackbot, start teleconference
15:47:13 [trackbot]
RRSAgent, make logs public
15:47:15 [trackbot]
Zakim, this will be WSRA
15:47:15 [Zakim]
ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start 17 minutes ago
15:47:16 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
15:47:16 [trackbot]
Date: 11 June 2009
15:47:59 [Bob]
rrsagent, this meeting spans midnight
15:49:53 [Zakim]
WS_WSRA(3 day)11:30AM has now started
15:50:00 [Zakim]
15:50:15 [Geoff]
Geoff has joined #ws-ra
15:50:32 [Bob]
zakim, ??P7 is Oracle
15:50:32 [Zakim]
+Oracle; got it
15:50:54 [asir]
asir has joined #ws-ra
15:52:22 [Zakim]
+ +0208234aaaa
15:52:45 [Bob]
zakim, aaaa is Paul
15:52:45 [Zakim]
+Paul; got it
15:53:40 [Bob]
zakim, Oracle has Yves, Geoff, Bob
15:53:40 [Zakim]
+Yves, Geoff, Bob; got it
15:54:13 [Bob]
zakim, Oracle has Asir
15:54:13 [Zakim]
+Asir; got it
15:54:29 [Tom_Rutt]
Tom_Rutt has joined #ws-ra
15:54:47 [Bob]
zakim, Oracle has Tom
15:54:47 [Zakim]
+Tom; got it
15:56:39 [Vikas]
Vikas has joined #ws-ra
15:56:58 [dug]
dug has joined #ws-ra
15:59:58 [li]
li has joined #ws-ra
16:00:00 [Bob]
zakim, Oracle has Prasad, Wu, Ram, JeffM
16:00:00 [Zakim]
+Prasad, Wu, Ram, JeffM; got it
16:00:10 [Zakim]
16:00:27 [Zakim]
16:00:55 [Zakim]
16:01:54 [Ram]
Ram has joined #ws-ra
16:02:13 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Ram
16:03:28 [Ram]
Scribe Ram
16:03:44 [Wu]
Wu has joined #ws-ra
16:03:58 [Bob]
chair: Bob Freund
16:04:24 [Bob]
scribe: Ram
16:05:09 [PrasadY]
PrasadY has joined #ws-ra
16:06:28 [Ashok]
Ashok has joined #ws-ra
16:07:42 [Ram]
Doug: Yesterday, when we talked about 6712, we removed the implied value. But we need to define an implied/default value for interop.
16:07:48 [dug]
This specification defines one ContentDescription URI, http://.../ContentDescription/Representation, to indicate that the child element is the literal representation of the resource.
16:08:21 [Ram]
Gil: Should this be another issue?
16:08:41 [Ram]
Dug: If this can be handled editorially, no need to open a new issue.
16:09:38 [Ram]
Dug: It is encumbent upon us to define an default URI, if the contentDescription hint is used.
16:09:50 [Ram]
Geoff: I need a little time to think about this.
16:10:06 [Ram]
Bob: OK. We will give Geoff more time and come back to this later.
16:10:12 [PrasadY]
PrasadY has joined #ws-ra
16:10:17 [Ram]
Issue 6401 discussion.
16:11:33 [Ram]
Gil: One of points of consensus yesterday was that existing WSDL tools be able to handle writing event sinks.
16:12:38 [Ram]
Gil: Recap: It is important to advertise notification types. As a developer, I should be able to look at a event source and identify the notifications. It is important to do this using existing WSDL based tools. It becomes murky when we talked about wrapped vs raw.
16:12:56 [Wu]
16:12:57 [Ram]
Gil: We need to re-examine the approach of wrapped notifications and think it over.
16:13:33 [Ram]
Geoff: Is the definition of notification a subset of message types?
16:14:03 [Ram]
Gil: Notification is defined to a SOAP message. Section 5 says notification can be ANY message. A subset of all notifications that exist out there can be described using a type.
16:14:22 [Wu]
16:14:59 [Ram]
Gil: Two notifications can have different wire contents and yet still have the same type. For example, one of them could be raw and the other wrapped.
16:15:25 [Ram]
Geoff: Is your description language describing any possible notification?
16:15:33 [Ram]
Gil: No.
16:15:39 [Ram]
Geoff: Is that a problem?
16:16:01 [Ram]
Gil: By describing a large subset of things you want to do, we can accomplish what is reasonable.
16:16:36 [Ram]
Gil: Are there any important use cases that cannot be handled by my approach?
16:17:08 [Ram]
Doug: Can anything that appears in a WSDL can appear as a notification?
16:17:30 [Ram]
Gil: This proposal has the effect of constraining which WSDL operations can appear as a notification.
16:17:47 [Ram]
Gil: With my approach, we cannot have application content in a SOAP header.
16:18:24 [Ram]
Dug: That is not correct. Your thing is not about wire presentation and hence it does not constrain.
16:18:30 [Ram]
Gil: Yes.
16:18:57 [Bob]
16:19:39 [Ram]
Geoff: I understand that. It appeared that the description language could not describe all things I could do in the WSDL.
16:20:20 [Ram]
Geoff: Can the WSDLs that are generated in your approach capable of generating WSDL as it would be produced by the raw approach.
16:20:44 [Ram]
Geoff: Would it cover all possible cases of WSDL usage?
16:20:45 [li]
16:20:58 [li]
16:21:29 [Ram]
Dug: The notification description describes the events, just like Schema describes data, and WSDL describes what is sent on the wire.
16:21:40 [Ram]
Dug: It is not meant to replace WSDL.
16:21:53 [Ram]
Dug: It is used as part of the WSDL.
16:22:10 [Bob]
ack wu
16:22:27 [PrasadY]
PrasadY has joined #ws-ra
16:22:32 [Ram]
Wu: There is a lot of commonality between the two approaches.
16:23:01 [Ram]
Wu: One question I have: How can an event sink know what service the source can offer from the notification type?
16:24:08 [Ram]
Gil: That is a separate issue. That is, how we are going to express this via policy. More work needs to be done.
16:24:35 [Bob]
zakim, who is on the phone?
16:24:35 [Zakim]
On the phone I see Oracle, Paul, Bob_Natale, Vikas, li
16:24:36 [Zakim]
Oracle has Prasad, Wu, Ram, JeffM
16:24:56 [Ram]
Gil: I am an event source. I support raw/wrapped, format/filters, etc. The purpose of this issue is to decouple the policy issue from the notification type. We should tackle them separately.
16:25:29 [Ram]
Wu: My point is very simple. An endpoint has a WSDL and I can tell by looking at the WSDL I can tell what notifications that service supports.
16:26:11 [Ram]
Gil: Without policy how do you know where to find the notification WSDL?
16:27:15 [Ram]
Dug: How does the event source describe the various formats, filters, it supports. That is a separate issue.
16:28:27 [Ram]
Wu: Event source today publishes event source and notification WSDL.
16:28:33 [Ram]
Gil: There is no notification WSDL.
16:28:56 [Ram]
Wu: Why can't we attach a notification WSDL to the source WSDL.
16:29:06 [Ram]
Gil: Via policy.
16:29:12 [Ram]
Wu: May be.
16:29:49 [Bob]
ack li
16:30:50 [Ram]
Li: My sense is that the difference between the proposals is the event source publishes the service description and how the sink consumes it.
16:31:52 [asir]
16:31:55 [Ram]
Li: It would help me if we understand in Gil's approach we can understand the steps from publication of Notification WSDL to the subscriber finding out about the Notification WSDL.
16:32:33 [Ram]
Li: The event source and sink would take the Notification WSDL and generate their own WSDLs. Are the generated WSDL on different sides communicated to the other side?
16:33:24 [Ram]
Li: Are they in sync? what is their purpose? It is just code generation?
16:34:12 [Ram]
Gil: I as a sink do not know what all notifications I may receive. The only way I can support this is via wrapped.
16:34:46 [Ram]
Gil: Let us say that I can handle a set of notification types (wrapped). I want to know about the raw notifications that are contained in the wrapped form.
16:35:24 [Ram]
I would do a Mex.GetMetadata call to get a description of the raw notifications.
16:36:07 [Ram]
Gil: The generated WSDL from the raw notification information may contain only the raw notifications that the sink is interested in.
16:36:44 [Ram]
Gil: This issue about WSDL compatibility is a funny one. It is possible to have different WSDL produce wire compatible messages.
16:37:32 [Ram]
Gil: Section F of my proposal says how the portype and other associated data is generated.
16:38:12 [Bob]
16:38:27 [Bob]
ack asir
16:39:04 [Ram]
Gil: It is not important that the event sink and source WSDLs match exactly. At a minimum, the Action URI and GED must match. My approach relies on doc-literal binding.
16:39:30 [Ram]
Asir:Gil: Notification WSDLs describes only the notification types.
16:40:54 [Ram]
Asir: I saw that you are mapping the independent notification types to a wrapped or a raw notification. How do you generate wrapped Notification WSDL?
16:41:16 [Ram]
Gil: The whole point about the wrapped Notification WSDL is that not all operations/notifications need to be described.
16:41:28 [li]
16:41:34 [li]
16:42:20 [Ram]
Gil: I may want to filter messages based on wrapped notification types, such as using XPath.
16:44:12 [Ram]
Dug: Gil's proposal provides a mechanism to provide additional data that may not be present in the WSDL.
16:44:38 [Ram]
Dug: This also includes information that may not appear on the wire. For example, topics and queues for notifications.
16:46:28 [Ram]
Li: The major difference in the proposal is why do we need a new metadata construct?
16:46:35 [asir]
I am still hazy on why we need a new metadata language, notification description
16:46:37 [Geoff]
16:46:42 [dug]
16:47:13 [Ram]
Li: Why can't we use the existing WSDL as UDDI does?
16:47:32 [Bob]
ack li
16:48:28 [Ram]
Li: Why do we need the notification description? WSDL can already do that!
16:48:53 [Ram]
Gil: You are correct that you don't need all the notification description. But at least we need the port type.
16:49:33 [Ram]
Gil: The qname of the GED and the Action URI associated with the port types are essential.
16:49:49 [Ram]
Li: In the notification description approach, the WSDL needs to be generated.
16:50:07 [Ram]
Gil: If you use only the wrapped notification, no need for WSDL generation.
16:50:19 [Ram]
Li: I am talking about raw event notifications.
16:52:36 [Ram]
Li: How do you do the serialization/deserialization of raw events? Don't you need a WSDL anyway for raw events?
16:53:46 [Ram]
Li: My question really is that I have problem understanding the critication advantage of notification description mechanism as opposed to simple WSDL approach.
16:55:20 [Ram]
Gil: It is hard to use the WSDL approach to do this.
16:55:32 [Ram]
Gil: What about typing?
16:55:57 [Ram]
Gil: Sorry what about topics? Notification descriptions provides us a nice mechanism to do the same.
16:58:16 [Ram]
Li: There are shortcomings where information cannot be captured in notification description.
16:59:32 [Wu]
16:59:42 [Ram]
Gil: Notifications map to one-way application message.
17:00:33 [Ram]
Li: The shortcoming is when you want to capture notification with acknowledgements.
17:00:36 [Zakim]
17:00:54 [dug]
17:00:56 [dug]
A one-way message sent to indicate that an event, or events, have occurred.
17:01:02 [Ram]
Li: WS-Eventing is a protocol establishes the channel. What flows on the channel should remain unconstrained.
17:01:48 [Ram]
Wu: How about we present our proposal?
17:01:49 [asir]
I think what Li is saying is that any proposals for 6401 should not interfere with the delivery model in Eventing
17:02:00 [Bob]
ack geo
17:02:05 [Wu]
17:02:28 [Bob]
ack dug
17:03:10 [Ram]
Dug: When the event source sends out only wrapped notifications, should the WSDL include the message descriptions for the raw notifications?
17:03:14 [Ram]
Li: No.
17:03:29 [Ram]
Dug: How does the sink get information about what the source supports?
17:04:12 [Ram]
Li: I will replace the notification description with a WSDL. The subscriber will use the WSDL to get that extra information.
17:05:49 [Ram]
Dug: Technically, you may be able to put the notification description into a WSDL. But are we not overloading the WSDL mechanism?
17:06:17 [Ram]
Dug: In both cases, I need to write custom code. Which is better?
17:06:25 [Ram]
Dug: There are pros and cons either way.
17:09:28 [Vikas]
Vikas has joined #ws-ra
17:20:28 [Zakim]
17:23:50 [gpilz]
gpilz has joined #ws-ra
17:23:53 [Ram]
Back from break.
17:24:01 [PrasadY]
17:24:10 [Ram]
Issue 6401 discussion continuation.
17:25:42 [dug]
17:25:48 [Ram]
Li to discuss his proposal.
17:26:01 [asir]
17:26:16 [gpilz]
17:26:22 [li]
17:26:48 [Ram]
Li: Go to Appendix A in the proposal.
17:27:15 [Ram]
Wu: This approach does not have any changes except Appendix A.
17:27:33 [Ram]
Asir: Can Li describe what problem he is trying to solve and what is the motivation.
17:27:57 [Ram]
Li: The motivation is to address the BP R2303 restriction about WSDL output-only operations.
17:29:11 [Ram]
Li: and to make WS-Eventing BP compliant.
17:29:58 [Ram]
Gil: I would like to know when you step through the linkages between the event notifications and notification description.
17:30:18 [Ram]
Li: This proposal is based on Gil's original idea.
17:30:46 [Ram]
Li: Go to Appendix A in the proposal.
17:32:50 [Bob]
ack asir, gpi
17:32:51 [Ram]
Li: Take the ouput-only operations in the source WSDL and put them in the Notification WSDL.
17:32:56 [Bob]
ack asir
17:33:00 [Bob]
ack gpi
17:33:54 [Ram]
Li: The idea is to replace offending operations.
17:34:03 [Ram]
Dug: Why do we need two WSDLs.
17:34:38 [Ram]
Li: The first WSDL is for the subscriber. The other is for the event source to have a normal request-response operations.
17:34:57 [Ram]
Li: The second WSDL is defined by the event source from the perspective of the event sink.
17:35:36 [Zakim]
17:35:42 [Ram]
Li: The subscriber can only choose what the event source can support.
17:36:22 [Ram]
Gil: Is the explicit goal of your proposal to make WSDLs Basic Profile (BP) compliant?
17:36:42 [Ram]
Li: Yes, Appendix A describes how to acheive that goal.
17:38:04 [Ram]
Li: If the event source conforms to Appendix A it can be BP compliant.
17:38:32 [Ram]
Li: The source published the Notification WSDL.
17:39:53 [Ram]
Li: Policy relates the Event WSDL to the Notification WSDL.
17:40:16 [gpilz]
state: correction: Is it an explicit goal of your proposal to support the migration of old-style, member submission WSDLs into WSDLs that are BP compliant?
17:40:36 [Ram]
Li: The event sink can use the policy to know about the linkage between the WSDLs.
17:41:46 [Ram]
Li: We have a policy wrapper, we have a policy assertion. The parameter serves as the link between the source and notification WSDLs.
17:42:45 [Ram]
Li: Would this work with policy intersection?
17:43:02 [Ram]
Correction: Dug: Would this work with policy intersection?
17:43:25 [Ram]
Asir: One the qname matching is done and there is no domain specific processing.
17:43:37 [Zakim]
+ +1.408.202.aabb
17:45:58 [Ram]
Asir: The proposal has one policy assertion whose name is out:outbound. That is the only qname used for policy intersection. The parameters are not used in the intersection.
17:46:30 [Ram]
Dug: The out:outbound qname is a single element and is static. Does this mean everything will match?
17:47:07 [gpilz]
the pseudo-schema in A.1 is incorrect - no big deal as we've figured out what was intended, but it shold be fixed to prevent later re-confusion
17:47:31 [Ram]
Asir: out:out-bound is the advertised behavior. When the behavior is engaged, there is a bag of additional information you can use that in in the policy parameters contained inside the policy assertion.
17:48:42 [Ram]
Gil: Li needs to write a psuedo schema to clarify this.
17:49:27 [asir]
Li - you may want to look at other psuedo schema examples in the eventing doc
17:50:09 [Ram]
Li: For the event source, it has to generate an event as described in the Notification WSDL.
17:50:28 [gpilz]
17:50:34 [Ram]
Li: For the subscriber, it has to subscribe to a specific Notification WSDL via the use of policy.
17:51:02 [Ram]
Li: The event sink has to implement the subscribe operation indicated by the policy parameter.
17:51:42 [Ram]
Gil: What are the attachment points? WSDL portype, binding, port element of a WSDL service.
17:52:00 [Ram]
Gil: We are looking at A.1.2.
17:52:34 [dug]
17:52:50 [Ram]
Li: Binding is not an attachment point, we do not see a case for it yet,.
17:52:57 [Bob]
ack gpi
17:53:02 [Bob]
ack dug
17:53:33 [Ram]
Dug: Why is the interace and binding element names different?
17:54:42 [Ram]
Li: If the WSDL has mixed inbound and outbound operations in a porttype, this process separates them into two port types. The policy links the two port types.
17:55:11 [jeffm]
jeffm has joined #ws-ra
17:55:30 [gpilz]
17:55:35 [Ram]
Li: A binding links to a port in WSDL and we use the same approach.
17:56:15 [Ram]
Dug: If you follow the binding link in the WSDL file, would you not end up in the same port type?
17:56:20 [Ram]
Li: You are quite right!
17:56:44 [Ram]
Li: Let me explain why we added this port type.
17:57:39 [Ram]
Li: If another standards body defines new event types, the policy can be used to link them. The implementation can use the policy link.
17:58:22 [Ram]
Li: We do not define binding, but only the port types.
17:58:57 [Ram]
Li: This proposal simply refactors the offending WSDL into Event WSDL and Notification WSDL without any binding information in them,
17:59:01 [gpilz]
18:00:54 [Wu]
In this approach, policy assertions with Endpoint Subject with the ability to describe the outbound operations in abstract WSDL to facilitate late binding.
18:02:01 [Ram]
Dug: The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy.
18:03:10 [Wu]
18:03:31 [Ram]
Dug: The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy.
18:03:41 [Ram]
The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy.
18:04:43 [dug]
18:04:48 [Bob]
ack gpi
18:04:48 [gpilz]
18:04:50 [Bob]
ack wu
18:04:53 [dug]
18:05:11 [Ram]
Wu: Let us press on with the description.
18:06:47 [Ram]
Gil: How do you check linkage consistency?
18:06:58 [Ram]
Li: We use the tools to traverse the linkages.
18:07:04 [Tom_Rutt]
18:08:37 [Ram]
Asir: Any consistency check needs to be done by the policy implementor.
18:08:50 [Bob]
ack om
18:08:56 [Bob]
ack tom
18:09:07 [Ram]
Tom: This is incredibly inventive. Anything that is processing this will need to handle this in a specialized way.
18:09:26 [Ram]
Tom: This seems like we are using policy in place of WSDL documentation.
18:09:44 [asir]
18:09:54 [Ram]
provides a way to describe as well.
18:10:06 [dug]
18:10:35 [Ram]
Wu: Policy is expressive and does what we want (linkage).
18:11:05 [Ram]
Wu: Policy is supported by tools. We followed Gil's proposal and extended it.
18:11:32 [gpilz]
18:12:01 [Bob]
ack dug
18:12:21 [Ram]
Dug: Is policy being actually used here or is it just for syntax?
18:12:45 [asir]
q+ to answer Doug's q
18:12:49 [Ram]
Dug: It seems that you are not establishing the link via policy but the linkage is done outside.
18:13:01 [Zakim]
- +1.408.202.aabb
18:13:22 [Zakim]
+ +1.408.970.aacc
18:13:31 [Wu]
The basic idea is to reverse the outbound operations in an event source WSDL to inbound operations in a separate WSDL called notification WSDL, and use WS-Policy assertions to link these operations.
18:15:26 [Bob]
18:15:46 [Geoff]
18:16:02 [Wu]
18:16:43 [Bob]
ack gpi
18:17:20 [Ram]
Dug: The policy is really a carrier and contains domain specific information.
18:19:12 [Bob]
ack asir
18:19:12 [Zakim]
asir, you wanted to answer Doug's q
18:20:10 [Ram]
Asir: Look at section A1. That explains the behavior.
18:21:29 [Ram]
Dug: What does the subscriber need to do?
18:21:50 [Ram]
Li: The subscriber needs to subscribe to the port based on the policy information.
18:22:46 [Bob]
18:23:02 [Bob]
ack geo
18:24:08 [gpilz]
18:24:51 [Ram]
Geoff: Dug mentioned the need to searching on notifications. It seems that requirements and design have gone beyond the original Appendix A replacement. It is good to have the set of requirements well defined.
18:25:49 [Ram]
Bob: The WG should not extend the issue beyond the original requirements/intent.
18:27:20 [Wu]
18:28:22 [Ram]
Li: Moving on to A.1.4. WSDL examples. I suggest looking at second example source. The notification WSDL is short.
18:31:15 [Zakim]
- +1.408.970.aacc
18:32:47 [dug]
18:33:09 [Ram]
Li is reviewing / describing the WSDL examples.
18:37:46 [Tom_Rutt]
18:37:51 [gpilz]
18:37:59 [Bob]
ack gpi
18:38:02 [Bob]
ack dug
18:38:52 [Ram]
Dug: I think I understand how when you are in an environment when the event source only sends notifications in one particular format, how the WSDL files can be traversed to reach the Notification WSDL.
18:39:32 [asir]
18:39:52 [Ram]
Dug: If the event source supports two wrapped notifications (wrapped1 and wrapped2), how do I know which WSDL to pick up?
18:40:53 [Ram]
Li: You start with the binding as you suggested. I will create two ports each corresponding to wrapped1 and wrapped2.
18:41:21 [Ram]
Dug: How do I know the association? What inside the WSDL tells me?
18:42:55 [Ram]
Dug: I have to know what I am looking for to know what I am looking for. If I already know what am I seaching for?
18:43:48 [Geoff]
18:43:49 [Ram]
Li: You traverse the policy and then indirect.
18:44:11 [Ram]
Gil: What if the outbinding has a qname that uniquely defined a notification format?
18:46:15 [gpilz]
state: correction: What if the out:Binding element had an additional attribute that had the value of the Format QName?
18:46:26 [Ram]
Li: In WS-Eventing, we have two formats: Wrapped and Unwrapped.
18:47:08 [Ram]
Li: We need to provide a link between the URI and WSDL; it is currently missing.
18:47:24 [Bob]
18:48:25 [Ram]
Dug: Subscriptions allow number of search types such as bookmarks, etc. How do I know which WSDL to grab. If it is just an URI I may have many WSDLs.
18:48:45 [Ram]
Dug: We need a linkage mechanism so the subscriber can find the right WSDL that matches.
18:51:24 [Ram]
Dug: The WSDL was there to advertise which events are sent. It is not just about BP compliant.
18:52:44 [Tom_Rutt]
the notification wsdl is constrained to have one binding per port. what did you mean when you talked about "surrogate" port which supports multiple bindings? Are you trying to get at a notification endpoint address which supports multiple notification service ports?
18:53:53 [Ram]
Gil: Issue 6661 deals with this. It is separate. But it is hard to separate doing the proposal for without touching it.
18:54:58 [Bob]
ack tom
18:54:59 [Ram]
Gil: Can the surrogate port support the raw format as well?
18:55:57 [Ram]
Li: Each port can support only one binding.
18:56:52 [Bob]
ack asir
18:57:07 [Ram]
Correction: Li: Each binding can support only one port.
18:57:28 [gpilz]
18:57:35 [Ram]
Asir: 6402 describes policy for event notifications.
18:58:32 [Wu]
18:58:51 [Bob]
time warning
18:59:03 [Ram]
Dug: These issue are different.
18:59:38 [Bob]
ack geoff
19:01:28 [Ram]
Geoff: In the proposal we had an appendix I. It is not broken. Just that it is not BP compliant. The core issue on the table was to turn what was in Appendix I BP complient. But I am seeing new things like format, etc. While these are important, it is not clear why we are mixing all these things together.
19:01:37 [dug]
19:02:17 [Ram]
Gil: Issue 6661 describes the problem. I claim that both my and Avaya's proposal addresses 6661 as it turns out.
19:02:36 [Ram]
Gil: Issue 6401 is different in scope.
19:04:42 [Ram]
Recess until 12:45PM PT. The meeting will reconvene at 12:45PM PT.
19:05:00 [Zakim]
19:14:11 [Zakim]
19:42:42 [Zakim]
19:43:26 [Zakim]
+ +0125660aadd
19:43:43 [li]
li has joined #ws-ra
19:43:55 [Paul]
Zakim, aadd is Paul
19:43:55 [Zakim]
+Paul; got it
19:44:45 [Zakim]
19:52:52 [asir]
19:52:56 [asir]
ScribeNick asir
19:53:02 [asir]
Scribe: Asir S Vedamuthu
19:53:08 [asir]
ScribeNick: asir
19:53:15 [asir]
Continuing 6401
19:53:38 [asir]
Back to traditional engineering
19:54:01 [asir]
Define problem, determine requirements, propose solutions, prove reqs covered and consider cost
19:54:31 [Wu]
issue 6401:
19:54:54 [asir]
Bob: appropriate to merge 6401 and 6661
19:55:03 [asir]
19:55:10 [asir]
Wu: scope of 6661 is not clear
19:55:16 [Wu]
19:55:59 [asir]
... someone should clearly articulate what needs to be addressed for 6661
19:57:02 [asir]
Bob: suggests that we merge 6401 and 6661, then march down the list (define problem, determine reqs, ...
19:57:16 [asir]
Wu: wants to ensure group consensus on what is the scope for 6661
19:57:55 [asir]
Bob: lets identify reqs
19:58:05 [asir]
... some of the reqs now
19:58:18 [asir]
Bob: are there any objections to merge?
19:58:30 [asir]
Wu: want to know what is 6661 all about, then merge
20:00:06 [asir]
Gil: the drill that Geoff and I plan to go through will describe the scope of the problem
20:01:15 [asir]
Bob: should we defer the engineering exercise to taskforce 6401
20:01:43 [asir]
... should we use the F2F
20:02:24 [Zakim]
+ +1.408.970.aaee
20:02:27 [asir]
... okay with using the F2F, but like to reserve some time for the formal objection
20:02:35 [asir]
[Gil jumped to the board]
20:02:54 [fmaciel]
fmaciel has joined #ws-ra
20:03:00 [asir]
Bob: any objections to consolidating these issues?
20:03:11 [asir]
Wu: we need to decide on the boundary first
20:03:25 [asir]
only two hours designated for this
20:03:35 [dug]
20:06:46 [asir]
[Talking about a possible Aug F2F]
20:06:54 [asir]
Bob: how about the first week of Aug
20:07:33 [asir]
Geoff: week of Aug 4th is fine with us
20:08:08 [asir]
Bob: we inadvertently scheduled Sep F2F because it conflicts with a religious holiday
20:08:44 [asir]
... Paul - can we do Sep 30- Oct 2nd?
20:09:09 [asir]
Action: Paul Nolan to check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd
20:09:09 [trackbot]
Sorry, amibiguous username (more than one match) - Paul
20:09:09 [trackbot]
Try using a different identifier, such as family name or username (eg. pnolan, pfremant2)
20:09:27 [asir]
Action: pnolan to check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd
20:09:27 [trackbot]
Created ACTION-71 - Check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd [on Paul Nolan - due 2009-06-18].
20:12:35 [asir]
Action: Geoff to check if MSFT could host a F2F meeting in the first week of August
20:12:35 [trackbot]
Created ACTION-72 - Check if MSFT could host a F2F meeting in the first week of August [on Geoff Bullen - due 2009-06-18].
20:13:01 [asir]
tentative location is Redmond, Aug 4-6th
20:13:31 [asir]
Hursley is also tentative from Sep 30-Oct 2
20:13:35 [asir]
back to 6401
20:13:43 [asir]
Trascribing the white board
20:14:21 [asir]
I. Developer of Event Sink generates code to dispatch and marshal Notifications using current WSDL tools a) raw notifications b) wrapped notifications
20:14:53 [asir]
II. Subscriber searches for a set of potential Notifications for elements that match a specific criteria
20:15:30 [asir]
III. Subscriber retrieves schema (s) for potential notification set for purposes for authoring appropriate filter expression (s).
20:15:53 [asir]
IV. Service designer describes abstract interface such that all implementations thereof will be Event Sources
20:17:27 [asir]
Amending I. c) Extension that impact on-the-wire mesages
20:21:15 [asir]
Extensions - subscription, formats, filter
20:21:22 [asir]
Gil: send bookmarks
20:23:06 [asir]
Bob: we have extension points
20:23:21 [asir]
... delivery, subscription, filter, format, endTo, notifyTo
20:23:33 [asir]
... and any future extension points
20:25:43 [asir]
... need to be feature-wise backward compatibility
20:30:22 [asir]
Geoff: shouldn't boil the ocean, are we trying to find one solution that solves all problems
20:30:28 [asir]
Gil: not so
20:31:55 [asir]
Geoff: may not be able solve for every possible extension
20:32:19 [asir]
... boil the ocean | set of things that definable and implementable
20:32:28 [asir]
Gil: add a non-functional requirement
20:33:01 [asir]
... I.c make these easy
20:34:34 [asir]
Bob: may be we can't do wrapped notifications, general extension points
20:34:52 [asir]
Geoff: there are 10 different dimensions of easiness
20:36:57 [Bob]
My point was that general extensibility points that affect the appearance of messages of the wire is not a new, unique, or unsolved concept
20:37:03 [asir]
Geoff: II sounds like brand new
20:37:14 [asir]
... not part of Eventing
20:37:41 [asir]
... how can a subscriber pick one and subscribe?
20:38:15 [asir]
20:38:42 [Bob]
ack gp
20:38:46 [Bob]
ack wu
20:39:02 [asir]
Wu: do we have to define II in the Eventing spec?
20:40:13 [asir]
Gil: am interested in weather notifications?
20:41:01 [Bob]
ack dug
20:41:12 [Wu]
20:41:41 [Bob]
ack asir
20:41:44 [Bob]
20:42:02 [li]
20:42:38 [asir]
Asir: what do you need for II in the protocol?
20:42:51 [Tom_Rutt]
20:43:56 [asir]
Gil: linkage between the event source and some endpoint that describes the set of notification types
20:44:20 [asir]
s/some endpoint/something/
20:44:32 [asir]
... want to know what that set of info would look like
20:45:32 [Tom_Rutt]
20:47:11 [asir]
II. Subcriber can see a set of potential notifications that may be emitted
20:47:30 [asir]
s/emitted/emitted by an event source/
20:47:31 [Bob]
20:47:37 [Bob]
ack wu
20:47:54 [asir]
the above sentence replaces II
20:47:57 [PrasadY]
20:47:59 [Bob]
ack li
20:48:29 [asir]
Li: who is the target for these use cases, people or machines
20:48:40 [asir]
Bob: struck search from the whiteboard
20:49:36 [Bob]
ack prasad
20:49:52 [asir]
Prasad: what about security? Subsriber may not have the authority to see all notifications
20:50:19 [asir]
Add a non-functional use case - II 'screened' based on authz
20:50:37 [asir]
Bob: more or less okay with I, okay with II
20:51:47 [dug]
q+ Asir
20:52:34 [dug]
q- Asir
20:53:19 [asir]
Annotate II with schema
20:55:27 [asir]
20:55:28 [asir]
II. Subcriber can see a set of potential notifications (including schemas) that may be emitted by an event source
20:57:15 [Ashok]
20:57:33 [asir]
II. Subcriber can see a set of potential Events (including schemas) that may be emitted by an event source
20:58:29 [dug]
20:58:30 [dug]
20:58:46 [asir]
Ashok: why don't we say metadata instead of schemas
20:58:48 [Wu]
20:59:16 [Bob]
ack dug
20:59:20 [dug]
21:00:15 [asir]
II. Subcriber can see metadata about a set of potential Events (including schemas) that may be emitted by an event source
21:00:22 [asir]
q+ GEoff
21:00:39 [Bob]
ack wu
21:00:43 [Bob]
ack geo
21:02:33 [asir]
Dropped III
21:03:09 [asir]
21:03:33 [Bob]
ack asir
21:04:06 [dug]
21:05:04 [asir]
lots of confusion about IV
21:05:11 [asir]
Li is summoned
21:06:23 [asir]
Li: walk through a use case from ECMA/348/CSTA
21:06:53 [dug]
21:07:11 [asir]
... we want to be able say .. make that WSDL BP compliant
21:07:27 [asir]
... want to separate those outbound operations to inbound operations
21:08:03 [asir]
... this is useful for other standard bodies, abstract event services, let the impl take care of details
21:09:03 [asir]
Doug: should we describe, providing a mechanism by which service designer can be handed an abstract interfaces that can be implemented as an Event Source
21:09:23 [asir]
21:10:03 [dug]
21:10:23 [Bob]
ack asir
21:11:21 [asir]
Asir: based on what I heard it appears that ...
21:12:08 [asir]
... A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source
21:12:13 [asir]
Doug: agrees
21:18:25 [asir]
Li: sounds okay
21:18:40 [asir]
III. A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source
21:19:25 [asir]
21:19:34 [dug]
21:19:38 [Geoff]
21:19:50 [Bob]
ack sir
21:19:56 [Bob]
ack asir
21:22:15 [asir]
IV. Realize I, II and II without metadata
21:23:24 [asir]
21:23:26 [Bob]
ack dug
21:23:58 [asir]
Doug: source supports sends out multiple variations of notifications
21:24:23 [asir]
... that is
21:24:37 [asir]
... source can support mutliple variations of notifications
21:26:00 [asir]
21:26:02 [asir]
V.Event Source can transmit multiple variations of Notifications (Raw, Wrapped, *)
21:26:03 [Wu]
source can support any combination of A&B in I
21:26:38 [Wu]
21:26:47 [Bob]
ack geo
21:28:56 [asir]
talking about stars on the sky
21:29:38 [PrasadY]
21:30:55 [asir]
okay with V
21:32:56 [Wu]
21:36:49 [Ashok]
21:39:43 [asir]
VI Proide Subscriber with metadata that describes the variations of Notifications
21:40:47 [dug]
21:42:04 [asir]
Geoff: Non-fuctional Requirement - all use case must have a 'reasonable' solution for constrained environments
21:42:22 [asir]
Bob: accepted
21:42:42 [Bob]
ack asir
21:42:49 [Bob]
ack wu
21:43:01 [asir]
Wu: are we going to dispose this in one short or incremental
21:43:05 [asir]
... divide and conquer
21:43:10 [asir]
Bob: premature q
21:43:16 [asir]
Wu: want to ask the question
21:43:40 [Bob]
ack prasad
21:43:45 [asir]
Bob: thinks the work is reasonable
21:45:54 [Bob]
state: Correction: An adquate spec ought to deal with these use cases
21:47:10 [li]
21:47:24 [asir]
s/thinks the work is reasonable/An adquate spec ought to deal with these use cases/
21:47:58 [Bob]
ack dug
21:48:31 [asir]
Doug: a mechanism by which a subscriber can determine the shape of the WSDL based on how it subscribed to an event source
21:50:19 [asir]
21:52:20 [Wu]
21:52:40 [Bob]
ack asir
21:53:58 [asir]
Asir: don't understand the usecase, what mechanism?
21:56:34 [Wu]
22:00:02 [dug]
A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source.
22:07:24 [Zakim]
- +1.408.970.aaee
22:17:25 [li]
22:24:50 [Zakim]
+ +1.408.970.aaff
22:24:59 [fmaciel]
zakim, aaff is fmaciel
22:24:59 [Zakim]
+fmaciel; got it
22:26:44 [asir]
Bob wants to add a non-functional req
22:27:29 [asir]
Bob: we need to finish the work, we started with a charter, to make it reasonable, need to limit invention
22:27:51 [Zakim]
22:28:10 [asir]
Bob: non:functional req: limit inventions to application of well known technologies
22:28:33 [li]
22:29:21 [asir]
Bob's non-functional req: limit inventions to application of well known technologies (such as WSDL, MEX)
22:29:35 [asir]
Bob: we have a limited scope problem, solutions should play within
22:29:36 [Wu]
22:30:04 [dug]
7: A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source.
22:30:21 [asir]
Bob: want to get to a draft that is more right than wrong
22:30:44 [asir]
here is the summary ....
22:31:09 [asir]
I. Developer of Event Sink generates code to dispatch and marshal Notifications using current WSDL tools a) raw notifications b) wrapped notifications c) Extension that impact on-the-wire mesages (example, new formats)
22:31:09 [asir]
Non-functional requirement - make it easy
22:31:09 [asir]
II. Subcriber can see metadata about a set of potential Events (including schemas) that may be emitted by an event source
22:31:09 [asir]
Non-functional requirement - II 'screened' based on authZ
22:31:10 [asir]
III. A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source
22:31:13 [asir]
IV. Realize ALL USECASCES without metadata
22:31:15 [asir]
V.Event Source can transmit multiple variations of Notifications (Raw, Wrapped, *)
22:31:17 [asir]
VI. Proide Subscriber with metadata that describes the variations of Notifications (eg supported formats)
22:31:19 [asir]
VII. A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source
22:31:22 [asir]
Non-fuctional Requirement - all use case must have a 'reasonable' solution for constrained environments
22:31:22 [asir]
Non-functional requirement - limit inventions to application of well known technologies.
22:31:49 [asir]
s/technologies./technologies (such as WSDL, Poliy, MEX)./
22:32:27 [Bob]
22:32:37 [asir]
Bob: gil to pick up the summary and turn this into a doc
22:33:28 [asir]
Bob: in the next meeting, we should review the draft reqs and deal with amendments
22:33:37 [li]
i have another requirement to add the next time
22:34:10 [asir]
Bob's picture is non-normative
22:34:44 [li]
22:35:50 [asir]
Topic: Sep F2F
22:36:03 [asir]
Scheduled for Wed Sep 30-Oct 2
22:36:06 [asir]
Hursley confirmed
22:36:33 [asir]
Action: Bob to send out a notice about the Sep F2F and other F2F meetings
22:36:33 [trackbot]
Created ACTION-73 - Send out a notice about the Sep F2F and other F2F meetings [on Bob Natale - due 2009-06-18].
22:37:14 [asir]
Action: Gil to transcribe the draft reqs from the minutes into a doc for review
22:37:14 [trackbot]
Sorry, couldn't find user - Gil
22:38:03 [Bob]
my camera may be non-normative, but it is very literal
22:38:15 [Bob]
Action: Gilbert to transcribe the draft reqs from the minutes into a doc for review
22:38:15 [trackbot]
Created ACTION-74 - Transcribe the draft reqs from the minutes into a doc for review [on Gilbert Pilz - due 2009-06-18].
22:40:27 [li]
bye folks be nice
22:40:44 [Zakim]
22:40:48 [Geoff]
22:41:52 [asir]
Resolution: Agreed to merge 6401 and 6661
22:41:56 [asir]
Topic: 6924
22:42:22 [asir]
Gil introduces his proposal
22:43:01 [asir]
22:45:20 [Bob]
ack geo
22:45:34 [asir]
Geoff: perhaps, change update denied to put denied (fault)
22:45:45 [asir]
Bob: any objections
22:45:46 [asir]
22:45:55 [asir]
22:46:06 [dug]
22:46:21 [asir]
Tom: is all or nothing on put?
22:46:26 [asir]
Gil: all or nothing
22:46:34 [Ashok]
Ashok has joined #ws-ra
22:47:53 [Bob]
A successful Put operation updates the current representation associated
22:47:55 [Bob]
with the targeted resource. An unsuccessful Put operation does not affect the resource.
22:48:25 [Bob]
ack dug
22:48:30 [asir]
Doug: am okay with the issue/proposal
22:48:47 [asir]
... it is important that a client knows what the server would do
22:49:35 [asir]
... include a flag that indicates what the server would do when it encounters read-only data
22:49:52 [asir]
Bob: where should we put that
22:49:59 [asir]
Doug: wiki :-)
22:51:52 [asir]
Bob: move to wiki
22:52:10 [asir]
Two amendments
22:52:29 [asir]
a) s/updatedenied/putdenied/
22:52:50 [asir]
b) A successful Put operation updates the current representation associated with the targeted resource. An unsuccessful Put operation does not affect the resource.
22:52:51 [PrasadY]
Could what the server would do with read-only data vary based on the specific resource, and may not be a generic one applicable across the board to all resources
22:53:17 [asir]
Resolution: accept + the above two amendments to resolve issue 6924
22:53:43 [asir]
Action: Doug to add the 6924 related metadata possibility to the wiki
22:53:43 [trackbot]
Created ACTION-75 - Add the 6924 related metadata possibility to the wiki [on Doug Davis - due 2009-06-18].
22:53:58 [gpilz]
gpilz has joined #ws-ra
22:54:00 [dug]
metadata == things to advertize
22:54:02 [asir]
Topic: 6956
22:54:51 [asir]
Geoff walks through the updated proposal
22:54:53 [asir]
22:55:05 [asir]
22:57:38 [asir]
Resolution: proposal accepted to resolve issue 6956
22:57:48 [asir]
22:58:10 [asir]
Thank you Ram!
22:58:27 [Ram]
Thank you Asir.
22:58:37 [asir]
ack asir
22:58:41 [Bob]
ack asir
22:59:45 [Zakim]
23:00:00 [Ram]
Bob: Discuss formal objection.
23:00:14 [Bob]
23:00:25 [Ram]
Geoff: Microsoft submitted a formal objection to issue 6398.
23:00:49 [Ram]
It is not about the process it is about a technical objection.
23:02:42 [Ram]
Geoff describes the technical objection.
23:03:32 [Ashok]
23:04:19 [Ram]
Geoff: There are other possibilities to address the technical objection. We should open up that issue and arrive at a mutually satisfactory solution for the problem at hand.
23:04:32 [Bob]
ack ashok
23:04:46 [Ram]
Ashok: You said that this is NOT a process objection.
23:05:27 [Ram]
Ashok: We had an issue and we closed it. So, are you reopening the issue?
23:06:19 [Ram]
Bob: The process allows for re-opening issues if new information is provided.
23:06:53 [Ram]
Bob: Anyone wants to discuss the technical objections raised by Geoff?
23:07:16 [Ram]
No comments from the WG.
23:07:46 [Ram]
Bob: Do Web service messages use well-known wrappers and actions?
23:08:01 [Ram]
Dug: Yes, many do, including the WS-RA specifications.
23:08:41 [Ram]
Bob: Why is this issue different? Anyone?
23:09:37 [Ram]
Yves: The current specification has Get wrapper and GetResponse wrapper. The specification is silent on what happens when the Get message is not wrappered but the GetResponse is wrappered.
23:10:01 [Ram]
Yves: If the wsa:Action is used to distinguish the message, then this problem should go away.
23:10:56 [Ram]
Geoff: WS-Transfer supported wsa:Action as the only way to dispatch. The issue (6398) resolution has changed that dispatch mechanism.
23:11:49 [Ram]
Yves: When you have two ways of expressing the same thing, there is room for contradiction. That is the real problem.
23:13:02 [dug]
23:13:55 [Bob]
ack dug
23:14:12 [Ram]
Yves: I propose using an anonymous wrapper or a single wrapper for all WS-Transfer operations.
23:14:31 [BobN]
BobN has joined #ws-ra
23:14:50 [Ram]
Dug: The right solution is to throw a fault if the wsa:Action and the wrapper does not match. I suggest opening a separate action.
23:14:52 [Wu]
23:15:05 [asir]
23:16:06 [Ram]
Dug: The information that is claimed to be new is not actually new.
23:17:01 [Ram]
Bob: That information was in a snippet of email but not raised or discussed on the floor. Maybe the sentence flew by but never teased out or discussed.
23:18:14 [Ram]
Bob: Is the point of it about a mismatch. That is, between the wsa:Action and the wrapper? Is that the problem?
23:19:35 [Ram]
Geoff: We have another problem. The WS-Transfer specification originally had wsa:Action as the only mechanism. That has been changed by the issue. This is the fundamental split. We need to continue to support wsa:Action as a mechanism to dispatch messages.
23:20:13 [Ram]
Bob: There are two points. One is in terms of dispatch (use of wsa:Action). Two is what happens if the wsa:Action and wrapper do not match.
23:20:35 [Ram]
Bob: Let us talk about dispatch mechanism.
23:21:13 [Ram]
Bob: WS-Addressing specifies wsa:Action as a mechanism to dispatch.
23:21:39 [Ram]
Asir: There have been other mechanisms in the past as well.
23:22:55 [Ram]
Bob: I do beleive we have a technical issue here. It is about dispatch relating to use of wsa:Action.
23:24:20 [Ram]
Geoff: Our objection is NOT about adding a wrapper.
23:26:00 [jeffm]
jeffm has joined #ws-ra
23:26:02 [jeffm]
23:26:08 [jeffm]
23:26:08 [Wu]
23:26:12 [jeffm]
23:26:30 [Ram]
Bob: What I would like to do at this time is to leave the resolution as is at this time and open two new issues. One issue would be about the wrapper name and wsa:Action and what happens if the wrapper name and wsa:Action are different. The second issue is about should the wrapper be the source of dispatch.
23:27:17 [Ram]
Gil: I would like to object to opening the issues.
23:27:39 [Ram]
Bob: I suggest opening the new issues.
23:27:44 [Ram]
Gil: Have we not formally accepted issues in the past?
23:28:51 [Ram]
Bob: We can either re-open the issue and deal with these two new issues or simply open only the two new issues.
23:29:24 [Ram]
Doug: Yves and Geoff can open separate issues and follow the normal process.
23:29:51 [Ram]
Bob: I want these issues to be opened.
23:30:54 [Ram]
Jeff: Where does that process say that the chair can open new issues at his/her own discretion?
23:31:07 [Bob]
23:32:12 [Ram]
Under 3.3.4 is the relevant section.
23:32:17 [Wu]
23:34:04 [Ram]
Asir: The situation was due to the 6398 resolution and we did not have sufficient information.
23:35:49 [Ram]
Bob: We just ran through a wrappering issue and we agreed to have the wrapper. Here we have a case where the charter says BP compliance. We had two proposals on the table one from Doug Davis and another from Geoff Bullen.
23:36:55 [Ram]
Bob: The chair conducted the vote and the issue was resolved in favor of Doug's proposal.
23:37:58 [Ram]
Dug: There is no new information. I just question the notion of new information being brough forth.
23:38:08 [Bob]
ack wu
23:38:25 [Ram]
Bob: Simply because something was on the mailing list does not constitute new information.
23:38:41 [dug]
23:39:21 [Ram]
Wu: We had thought that the issue was about BP compliance. But we never understood that the mismatch between wrapper and wsa:Action is a problem. I agree with Yves.
23:39:59 [Bob]
ack asir
23:40:02 [Bob]
ack jeff
23:40:04 [Ram]
Wu: I support opening the new issue to deal with the mismatch between the wrapper and wsa:Action.
23:40:11 [Tom_Rutt]
23:41:11 [Ram]
Jeff: Oracle objects to the way this is being handled.
23:41:24 [dug]
IBM agrees with Oracle
23:41:32 [Bob]
ack dug
23:41:59 [Ram]
Dug: You said that email does not constitute new information.
23:42:15 [Ram]
Bob: Yes, the information was not discussed.
23:42:29 [asir]
23:42:50 [Ram]
Dug: At that time, Geoff did not discuss that. How does that then become new information?
23:43:18 [Ram]
Bob: Wu asked for more time at that time. Wu please clarify.
23:43:51 [Ram]
Wu: We never discussed how the wrapper should be designed.
23:45:07 [Ram]
Bob: I like to open an narrowly scoped issue that deals with the technical component of the prior issue relating to wrappering and discuss it.
23:46:29 [Ram]
Tom: What happens if the message does not obey the WSDL?
23:47:23 [Ram]
Tom: WS-I BP tools could do compliance. I suggest opening new issues just like any other new issues.
23:48:24 [Ram]
Geoff is in the process of opening new issues.
23:48:47 [Bob]
23:48:52 [Ram]
Yves: There are people who use Web services who do not use WSDL.
23:48:55 [Bob]
ack tom
23:50:31 [Ram]
Dug: The WSDL is normative and defines the contract.
23:51:26 [asir]
23:51:45 [Ram]
Dug: If the Subscribe message has wrong format, what happens?
23:52:29 [Bob]
23:53:13 [jeffm]
23:53:30 [Tom_Rutt]
23:53:47 [Bob]
ack asir
23:53:53 [Bob]
ack jeffm
23:54:14 [Ram]
Asir: Our objection is on the outcome of the issue resolution. We will defer to you whether you want to reopen or process the technical objections as new issues.
23:54:28 [Ram]
Jeff: All bets are off, if you violate the specification.
23:54:34 [Bob]
ack tom
23:54:45 [Ram]
Tom: I have a confusion about what 'dispatch' means.
23:55:04 [Ram]
Tom: I object to this issue.
23:55:09 [dug]
23:55:31 [Ram]
Gil: I need more time to process this issue.
23:55:47 [Ram]
Gil: Can we discuss accepting the issue at the next meeting?
23:56:01 [Ram]
Dug: I need more time too.
23:56:08 [Ram]
Bob: I don't want to rush anyone.
23:56:24 [Tom_Rutt]
ws addressing core states: "The [destination] and [action] properties indicate the target processing location and the verb or intent of the message respectively. The values of these properties can be used to facilitate the dispatch of messages." that is the only use of the word "dispatch" in the spec
23:56:27 [Wu]
23:56:36 [Ram]
Dug: The issue says: "Replication of information reduces interoperability". I don't understand that.
23:56:42 [Bob]
ack dug
23:56:51 [Tom_Rutt]
this is a non normative statement, the concept of dispatch is implmentation dependant
23:56:52 [Ram]
Dug: WS-Addressing replicates information.
23:57:53 [Ram]
Dug: Interoperability problems occur due to ambiguities in the specification.
23:58:21 [Ram]
Dug: I need more information.
23:58:21 [Bob]
ack wu
23:58:53 [dug]
23:59:17 [Ram]
Wu: I want to make a constructive suggestion. I think the issue proposal is very clear. I suggest we open issue and discuss it.
23:59:59 [Ram]
Gil: I would like to make sure that the issue is well described. My intent is not to reject this issue.
00:00:45 [asir]
Not sure why RM comes into play all the time!
00:00:53 [dug]
its a lovely spec
00:00:57 [asir]
00:01:01 [Ram]
Dug: The premise of the new issue is in question or incorrect. Therefore, we should not accept this issue. Therefore, we need to discuss whether we need to open this issue.
00:01:05 [asir]
I think you wanted to use MC
00:01:10 [dug]
I thought about it
00:02:01 [Ram]
Bob: The new issue in an unopened/unaccepted state. Comments can be made to amend the issue.
00:02:32 [gpilz]
gpilz has left #ws-ra
00:03:20 [Ram]
Bob: IBM confirms that the new dates for the September F2F. I will send a confirmation email to the WG.
00:03:26 [Bob]
rrsagent, generate minutes
00:03:26 [RRSAgent]
I have made the request to generate Bob
00:03:37 [Ram]
Meeting adjourned. 5:03pm PT.
00:04:56 [Zakim]
00:04:58 [Zakim]
00:05:04 [PrasadY]
PrasadY has left #ws-ra
00:09:59 [Zakim]
00:10:00 [Zakim]
WS_WSRA(3 day)11:30AM has ended
00:10:01 [Zakim]
Attendees were +0208234aaaa, Paul, Yves, Geoff, Bob, Asir, Tom, Prasad, Wu, Ram, JeffM, Bob_Natale, Vikas, li, +1.408.202.aabb, +1.408.970.aacc, +0125660aadd, +1.408.970.aaee,
00:10:03 [Zakim]
... +1.408.970.aaff, fmaciel, [Oracle]