15:55:57 RRSAgent has joined #ws-ra 15:55:57 logging to http://www.w3.org/2009/08/05-ws-ra-irc 15:55:59 RRSAgent, make logs public 15:55:59 Zakim has joined #ws-ra 15:56:01 Zakim, this will be WSRA 15:56:01 ok, trackbot; I see WS_WSRA(F2F)11:30AM scheduled to start 26 minutes ago 15:56:02 Meeting: Web Services Resource Access Working Group Teleconference 15:56:02 Date: 05 August 2009 15:56:20 rrsagent, this meeting spans midnight 15:57:35 WS_WSRA(F2F)11:30AM has now started 15:57:43 +[Microsoft] 15:58:37 Vikas has joined #ws-ra 15:59:45 +Yves 15:59:46 +Vikas 16:01:30
  • li has joined #ws-ra 16:02:13 +li 16:02:40 Ram has joined #ws-ra 16:07:10 scribe: Ram 16:07:17 dug has joined #ws-ra 16:07:18 scribenick: Ram 16:08:25 agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0025.html 16:08:34 q+ 16:09:31 ack dug 16:10:23 q- 16:10:36 Wu has joined #ws-ra 16:10:49 scribe ram 16:11:05 Bob: I have sent a re-ordered agenda for the rest of the meeting. 16:13:41 Re-ordered agenda is accepted. 16:13:54 Geoff has joined #ws-ra 16:14:07 asir has joined #ws-ra 16:14:21 Issue 6432 16:14:37 Sreed has joined #ws-ra 16:14:52 DaveS has joined #ws-ra 16:14:54 Tom_Rutt has joined #ws-ra 16:15:45 Bob explains the issue and the progression so far. 16:16:20 Ram posted a link http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432 16:19:14
  • q+ 16:19:15 Bob says: Add the word 'the' in front of the phrase "such as". 16:20:05 s/in front of/after 16:20:23 ack li 16:20:48 q+ 16:20:51 Yves: Suggest that eh capital MAY be changed to a "may" 16:21:03 s/eh /the / 16:21:52 gpilz has joined #ws-ra 16:22:02 ack dave 16:23:30
  • where is the header in previous text? 16:24:22
  • ram: header is important and it should be defined in mc itself 16:24:46 Dave: Change the MAY to may. 16:24:58 Dave: This would make it clearly non-normative. 16:25:21
  • agree with ram 16:25:28 q+ 16:26:59 ack geo 16:28:08 q+ 16:29:40 Ram: It is sufficient to note that the proposal uses a non-normative reference to WS-MakeConnection. No need to test. If companies are willing to test this that is fine but it is not necessary to pass CR. 16:30:08 ack yves 16:30:39 change to ...A subscription manager MAY choose mechanisms,.. 16:32:27 well, in order to communicate, they will have to do something. the MAY is really unneccessary 16:32:30 Ashok has joined #ws-ra 16:32:35 s/cc/c/ 16:32:42 change to ...A subscription manager MAY choose to support mechanisms,.. 16:32:51 ack wu 16:33:14 after that if they have to use WS-MC, then so be it, I have nothing against it :) 16:35:40 For revised proposal for 6432 see comment #8 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432 16:35:41 q+ 16:38:12 Wu: Need a way to indicate MC is used in NotifyTo. 16:39:03 ack dave 16:39:05 q+ 16:39:14 q- 16:40:06 Wu and Yves are fine with the latest revised proposal (comment #8). 16:40:26 Dave: Fine with the latest edits. 16:41:01 Bob: Are members OK with proposal. Any objections? 16:41:15 No objections. Issue resolved. 16:41:23 Issue 6432 resolved. 16:42:33 Issue 6724 discussion. 16:44:11 Geoff: There is a proposal from Doug (comment #4) in the bug report. I have a subsequent proposal as well in the bug report. 16:44:41 q+ 16:45:13 Geoff: The general question here is if there is value in creating an explicit resource representation of a subscription. No need to have two ways of doing the same thing. Since we have gone down the route of using explicit operations, we should continue to use it. 16:46:25 q+ 16:46:47 Geoff: No need to define a Transfer resource representation for a subscription manager. 16:47:43 ack dug 16:48:38 Doug: Geoff' proposal does not address many problems. It is possible to take Geoff's proposal and address those problems. 16:49:42 Doug: If we choose NOT to use WS-Transfer operations, we need to add explicit operations to address the gaps. 16:49:58 Doug: However, there are some caveats. 16:50:19 q+ 16:50:22 Doug: We need to find a way to get statistical information such as number of subscriptions, etc. 16:50:22 q+ 16:51:36 Geoff: The extensibility mechanism can allow for such statistical queries. 16:52:21 Geoff: Would it be acceptable to get past this point by agreeing to some generic getMetrics() operations? 16:52:40 Doug: It probably may work. I need to think a bit more. 16:52:47 ack dave 16:53:34 Dave: There is nothing in the spec that prevents us from composing with WS-Transfer. WS-Eventing is a targeted 80/20 use case. The getStatus() does that. The addition of more operations or linkage to WS-Transfer complicates this. 16:57:08 Dave: No need to have two ways to do the same thing. It is hard to make drastic changes. 16:57:18 ack gpi 16:57:32 Gil: Dave said most of what I wanted to say. 16:58:05 Gil: Do you need to add new operations to WS-Eventing and WS-Enumeration and so on? 16:58:25 q? 16:58:55 q+ 16:59:27 ack bob 17:00:05 Bob: I am speaking as Hitachi rep not as a chair. First off, optionality begets profilidity. 17:00:39 Bob: We have got frankly an organization (Hitachi) a bit schizophrenic with the issue of optionality. 17:01:00 Bob: The device people are of the feeling that if it is optional they would not do it. 17:01:21 Bob: They do not want new features. 17:01:37 Bob: They are so concerned about message size. 17:03:46 Bob: The large systems people are concerned about consistency / coherency of data as retrieved by queries. 17:04:17 The large systems people have no problems with policy. 17:05:12 q+ 17:05:15 Bob: The devices and large systems people do not want any get operations. 17:05:28 Bob: I propose to close this issue with no action. 17:05:54 q+ 17:05:59 ack geo 17:06:34 ack wu 17:06:36
  • +1 bob 17:06:51 ack dug 17:07:17 +1 bob 17:08:03 Doug: I don't agree. 17:08:53 ack yves 17:09:18 Doug: I would like to explore a possible proposal with Geoff and come back to this. There are some genuine reasons why people want this. 17:09:45 Yves: There are some security concerns. I understand that you may want to do such things, but it may be better to do this on the receiving side. 17:09:56 Yves: I prefer to have a constrained approach for security reasons. 17:12:42 q+ 17:12:51 ack dave 17:13:04 Bob: Is there an interest to pursue the option of Doug and Geoff working together to propose a revised proposal. 17:16:44 Bob: Straw poll to close with no action or delay and produce a proposal. 17:17:22 jeffm has joined #ws-ra 17:17:53 Close with no action: Microsoft, Avaya, CA, Fujitsu, Hitachi. 17:18:28 Delay: Oracle. 17:18:40 Add W3C to Close with no action. 17:19:15 -Vikas 17:19:21 Action: Doug to come back witth a new proposal for 6724 before next meeting. 17:19:21 Created ACTION-88 - Come back witth a new proposal for 6724 before next meeting. [on Doug Davis - due 2009-08-12]. 17:27:37 Corrections to straw poll results on 6724. 17:27:53 Close with no action: Microsoft, Avaya, CA, Fujitsu, Hitachi, W3C. 17:28:02 Delay: IBM, Oracle. 17:29:22 Dave: I am willing to wait to see a proposal if it can be turned around quickly. 17:35:32 action: Doug to define a new proposal for 6724 for consideration on 2009-08-18 17:35:32 Created ACTION-89 - Define a new proposal for 6724 for consideration on 2009-08-18 [on Doug Davis - due 2009-08-12]. 17:36:21 Issue 7159 discussion. 17:37:39 q+ 17:38:24 q+ 17:38:36 q+ 17:38:49 ack gp 17:38:53 Doug: No need to repeat what is said in WS-Addressing. 17:39:00 Gil: +1 17:39:21 ack dave 17:39:42 ack geo 17:39:52 Dave: We can drop the referred to text. 17:40:02 Geoff: Can we simply say what Transfer spec says? 17:40:12 Bob: Any objections to Geoff's proposal. 17:40:26 7159 resolved with wording in Transfer. 17:41:01 cool 17:41:35 6917 issue discussion. 17:44:01 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0093.html 17:44:12 and http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0094.html 17:44:22 and http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0095.html 17:44:44 Gil explains his prposal. 17:46:19 Gil: There is a description and runtime aspect to the problem. 17:46:52 Gil: What do I filter based on multiple tags? 17:47:01 q+ 17:47:43
  • q+ 17:47:53 q- 17:47:55 Ashok: Let us leave it as something we need to talk about. 17:49:13 Gil: These tags need to be disambiguated. 17:51:24 q+ 17:52:11 ack li 17:53:29 Li: I like to treat these problem in two aspects. One is do we need to compose with WS-Topic. This is the source of this issue. The performance issue is with content based filtering. 17:53:58 Li: The other aspect is open-ended. Do we need to create another filtering mechanism besides WS-Topic. 17:54:45
  • http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0176.html 17:55:35 Li: Option 1 is do nothing. WS-Topic can compose with WS-Eventing. 17:55:45 Li: Option 2. WS-Eventing can profile WS-Topic. 17:56:10 Li: Option 3: WS-Eventing says something such as WS-Topic can be used for content filtering. 17:56:18 q+ 17:56:22 ... 17:56:42 +1 Li 17:57:47 Geoff: Question for Gil. It seems that event tags are static for each event. Is it true? 17:58:12 q+ 17:58:16
  • we need to answer two questions 1) if and how to compose ws-topic; 2) another filtering mechanism 17:58:18 ack geo 17:58:19 Geoff: I would like to understand if WS-Eventing can compose with WS-Topic? 17:59:13 Gil: The question about whether the event tags are static is a bit complicated. It could be static and dynamic. 18:01:31
  • q+ 18:03:50 ack ashok 18:05:22 Ashok: Why can't the tags be part of the data content. Close this issue with no action. 18:05:39 Doug: Think of the tags are metadata. 18:05:42 q+ 18:07:54 ack dave 18:09:08 Dave: WS-Topic is infested with references to WS-Notification. While it is possible to compose WS-Topic with WS-Eventing, it is not so as it is. One may need to profile WS-Topic to make it composable with WS-Eventing. 18:10:17 Dave: I would not recommend using WS-Topic in WS-Eventing. We could use the event description tags (part of 6401 issue proposal) and describe how to use the WS-Topic tags. 18:11:13 ack li 18:11:41 Li: We talked about tagging. There is a W3C Recommendation SAWSDL. 18:12:14 q+ 18:12:34 SAWSDL 18:14:18 Bob: Do you have an idea of what it would take to make SAWSDL compose with WS-Eventing? 18:14:29 http://www.w3.org/TR/sawsdl/ 18:15:08 http://www.w3.org/TR/sawsdl/#external 18:15:14 (external annotations) 18:15:38 q+ 18:15:41 yves, RDF annotations, correct? 18:15:46 yes 18:16:22 http://www.milwaukeeconnect.com/webapp/wcs/stores/servlet/product_27_40028_-1_747354_201248_192137 18:16:34 Wu: If we want to tag, we should use SAWSDL. 18:16:38 q+ 18:17:02 Wu: But there is complexity involved in that process. 18:17:20 ack geo 18:17:20 Wu: A better way is to extend the specification for tagging purposes. 18:17:50 Geoff: There are a whole lot of approaches here. There is also complexity. 18:18:18 Geoff: I am getting concerned that this will end up being a long pole. 18:18:24
  • q+ 18:18:29 actually, SAWZALL 18:18:31 s/pole/pull 18:18:58 Geoff: If this purely a performance thing and NOT a functional thing, can't we address this via some guidance on composition? 18:19:03 ack dave 18:19:27 We just need to say WS-E can be extended, e.g. through tagging using SAWSDL, to allow fast filtering 18:19:37 ack wu 18:19:55 Dave: We do have an interoperable way if not the performant way. 18:20:30 Dave: My inclination is to do the right thing - close this with no action. Put some guidance in the primer. 18:21:51 Bob: Does anyone have any objections? 18:22:03 Bob: We need to send a note to the issue submitter. 18:22:34 Dave: I volunteer to send the note to the issue submitter and mention about how we intend to discuss this in the primer. 18:24:05 q- 18:24:37 ack li 18:25:10 Bob: Issue closed with no action. 18:25:49
  • q? 18:26:17 Issue-7204 Eventing: Delivery policy for delivery mode extension 18:28:51 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7204 18:29:54 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0050.html 18:30:25 q? 18:32:58 Wu explains his proposal. 18:37:21 Ashok: Typically, we do not have policy on a message. We only have policy on endpoints. 18:37:25 q+ 18:37:30 ack dave 18:38:01 Dave: This is a question. Is this similar to how RMPolicy works? 18:38:05 Asir: No. 18:38:13 Ashok: Why not? 18:39:38 Wu: The idea is to decorate the Delivery element with the options you would support. 18:40:18 q+ 18:40:29 q+ 18:41:16 q+ 18:41:42 ack bob 18:42:47 Bob: WS-Policy is used to advertise a bunch of capabilities. 18:43:27 Bob: at the WSDL level. 18:44:58 Bob: What is the need to use policy in an atypical way? 18:45:25 Wu: The problem is with QNames and how to interpret them. 18:46:50 Wu: Policy allows composition and clear semantics. 18:47:27 Bob: Why not use the typical WSDL policy attachments and do it upfront? 18:48:07 q? 18:49:06 ack dave 18:49:37 Dave: Close with No action. 18:50:11 gpilz has joined #ws-ra 18:50:20 Bob - I'd like to have some time after lunch to talk about the incorporation for 7159 - just 5 mins 18:50:37 Dave: The sink needs to know what it wants and should get the WSDL that it desires. No need to invent a poilcy framework since everything I need is in WSDL. 18:50:58 Dave: The WSDL definition for the sink has all the necessary information. 18:52:47 q+ 18:53:13 Wu: What in policy prevents using push and pull together. 18:54:21 q- 18:55:19 How would wu’s proposal would allow the following type of delivery extension: 18:55:21 Add an extension to provide an alternateNotifyTo epr element. If an element of this QName is present in the delivery element, the semantics of the extension are that the event source can use the epr in the alternateNotifyTo element child of the deliveryElement to send the event delivery operation to if the primary NotifyTo address is unavailable for any reason. 18:55:23 I do not understand how wu'sr proposal could handle such an extension, since I do not where the alternate epr would be carried in the subscribe request. 18:55:26 ack tom 18:57:18 Ashok: SHould the EPR goes into the policy assertion? 18:57:35 Doug: Shouldn't NotifyTo EPR also go into policy assertion? 18:58:19 Bob: Let us wrap up this discussion. Who feels this proposal is accepable? 18:58:47 Who feels that this issue be closed with no action. 18:58:55 gpilz1 has joined #ws-ra 18:59:01 Oracle, Fujitsu and IBM say close with no action. 18:59:40 Microsoft needs more time. 19:00:00 Bob: Would Aug 18th work? 19:00:10 Asir: Let us revisit after lunch time,. 19:00:19 Lunch break. 19:00:38 Break until 1pm Pacific Time. 19:00:42 -li 19:01:28 -Yves 20:04:14 +li 20:06:11 http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Faults 20:06:28 scribenick: gpilz1 20:06:39 TOPIC: 7159 20:06:48 DaveS has joined #ws-ra 20:06:54 http://www.w3.org/2002/ws/ra/edcopies/wsenum.html#Faults 20:07:01 Doug: issue about cleaning up fault language around WS-Addr 20:07:16 ... text is inconsistent across all specs 20:07:26 ... first section should be boilerplate 20:07:32 ... some had slightly different text 20:07:50 ... WS-T doesn't even describe mapping of faul infoset to XML 20:08:35 ... WS-Enum says MUST include fault action URI, WS-T says should, others (?) don't say anything 20:09:06 ... would like to start out with consistent language across all specs (with MUST) and raise an issue, if necessary, if people disagree with the MUST 20:09:24 Bob: comments? 20:09:43 DaveS: we can raise a separate issue for separate specs if need be 20:10:04 RESOLVED: Doug to make fault text consistent across all specs 20:10:40 TOPIC: 7205 20:10:54 +Yves 20:11:13 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7205 20:11:18 -Yves 20:11:22 Wu: (reviews issue) 20:12:17 +Yves 20:13:51 Ashok has joined #ws-ra 20:13:53 Bob: questions? 20:13:55 q? 20:13:55 q+ 20:14:02 ack geo 20:14:22 Geoff: the submission spec had a fault that returned the set of supported Modes 20:15:02 ... we've now got a set of QNames in wse:Delivery, you could get a case (e.g. Push/Pull) that doesn't make sense 20:15:31 ... first question is: did the submission spec do this as a simple means of negotiation? 20:15:46 ... do we still think that is a relevant thing to do? 20:15:52 ... is it useful? 20:16:07 ... if we do think it is useful, we need to figure out what to return 20:16:58 Bob: in the submission version, the element that held detailed info on supported Modes was optional 20:17:16 ... I have previously expressed my reservations about extension negotiation using faults 20:17:43 ... if we need a negotiation mechanism, is WS-Policy enough? 20:18:03 ... if we don't do that, a more reliable mechanism would be to return something in SubscribeResponse 20:18:53 ... (speaking not as a chair for the above and the following) 20:19:12 ... in previous specs, using faults to carry important information is not a good idea 20:19:24 Wu: if we have Policy we don't need to worry about the fault codes 20:20:33 Bob: you think there is a need to have an active mechanism to negotiate extensions built into the protocol? 20:20:41 Wu: yes, we should use Policy 20:20:50 ... that way we don't need to invent anything 20:21:16 DaveS: you are saying that, if we use Policy we won't need this? 20:21:19 Wu: yes 20:21:34 Tom: Policy doesn't have a negotiation framework, how would that work? 20:22:04 Doug: I think that, when Wu says "use Policy" he means "use my proposal for using Policy to negotiatie extensions" 20:22:19 Wu: correct, I am profiling WS-Policy to meet a specific need 20:22:42 Geoff: isn't it kind of sufficient if the Source advertises it's Policy in the Event Source WSDL? 20:23:02 ... we've already noted that we need to define an assertion that indicates "I support WS-Eventing" 20:23:30 ... I'm assuming this would support things like Delivery extensions as well as support Formats, Filters, etc. 20:23:44 ... If we did that, would that satisfy your requirements Wu? 20:25:18 Wu: (agrees that WS-Policy is optional) 20:25:51 ... if you only specify the QName sequence in the Delivery wrapper, how do you separate them? 20:26:03 Geoff: I want to separate this issue from the first one 20:26:17 ... Want to figure out what, if anything, needs to be returned in "the fault" 20:26:25 q+ 20:26:34 ... Policy is optional so you may not have Policy when you do the Subscribe 20:26:44 ... and you may not send anything back on a fault 20:26:48 ... and that could be OK 20:27:06 ack dave 20:27:25 DaveS: this model of "try something and, if it doesn't work, tell me what I can use" is there a default that always works? 20:27:31 All: (yes) 20:27:36 DaveS: then we don't need this 20:28:02 ... You can always fall back to what you know works. This idea of tell you what works when you try something that doesn't work is a duplication of effort. 20:28:24 Wu: what happens if client does not support Policy and an extension isn't accepted 20:28:38 DaveS: then the client should fall back to what is known to work 20:28:43 Wu: there is one complication 20:29:06 ... under the current spec, we have these default mechanism where there is nothing inside wse:Delivery 20:29:17 Geoff: incorrect, you have to have at least one element 20:29:26 Wu: is that specified in WS-Eventing? 20:29:32 All: (yes) 20:29:45 Geoff: there is a subtelty here - there is no default 20:29:57 ... you have to have something in wse:Delivery 20:30:16 ... but you could have an Event Source that didn't support NotifyTo but instead support "From" 20:30:37 DaveS: but there is no "must support" attached to NotifyTo? 20:30:40 Geoff: yes 20:30:43 DaveS: ouch 20:30:50 ... not sure I like the strategy for this 20:31:11 ... if there isn't a default solution that we know is going to work (from reading the spec) 20:31:42 ... then it is a little unfair to developers/clients not to provide a default which is known to work in all cases 20:31:57 Doug: I'm not sure you can do that 20:32:16 ... we can't require WS-Policy, we can't require people to support NotifyTo, etc. 20:32:23 ... we don't have any alternatives 20:32:50 Geoff: we need to figure out the simplest, poor mans approach to providing a default that is known to work in all cases 20:33:09 DaveS: we don't have to provide something, but it is good spec ettiquite 20:33:40 Doug: another constraint - I would have to have the "poor man thing" be radically different than the "rich man thing" 20:33:54 ... two completely different mechanisms is untenable 20:34:04 q? 20:34:13 ... if there is a poor man/rich man, the rich man needs to be an extension of the poor mans scheme 20:34:31 Geoff: does this lead to WS-Policy in extension negotiation 20:34:44 Doug: not necessarily 20:35:12 ... if you want to find out what the Event Source supports you need to look at its WSDL and see what WS-Policies are advertised there 20:35:24 ... to do something else is to invent a new policy language 20:35:43 Bob: I think we need to retain a fault that needs to be generated if there is "some nonsense" 20:36:00 ... the detail element needs to say "the source of the nonsense is *this*" 20:36:01 q+ 20:36:17 ... that faulting mechanism already exists 20:37:23 ... extension writers are going to write their extensions any way they want 20:37:46 Geoff: device people may create a fault that contains important info in the fault detail 20:37:50 ... we can't stop them 20:38:00 Bob: (?) 20:38:16 Geoff: if we are going to specify something, it shouldn't be in the fault it should be in SubscribeRespone 20:38:25 Bob: or some kind of "probe" mechanism 20:38:35 Asir: but that doesn't exist today 20:38:40 Bob: no, it doesn't 20:38:49 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0050.html 20:38:59 ack dug 20:39:01 Geoff: MEX exists but, in this case, MEX would return policy 20:39:10 Doug: trying to figure out where we are 20:39:23 ... we have a fault in Section 6.6 that says 20:39:31 This fault is sent when the event source is not capable of fulfilling a Subscribe request for local reasons unrelated to the specific request. 20:39:54 ... maybe we should remove the "for local reasons unrelated to the specific request" part 20:40:14 ... we have 2 different types of faults here; one is similar to a mustUnderstand fault 20:40:30 q+ 20:40:44 ... if you detect a QName that you don't recognize and you choose not to ignore it - you can generate this fault 20:40:46 q+ 20:40:56 ack geoff 20:42:17 Geoff: there is a subtetly here; the is the mU header fault, there is "this one" (internal fault), then there is the case where you specify an arbitrary set of extensions that I understand, but their combo doesn't make any sense 20:43:20 Doug: I understand the extension - I think we should merge the "internal processing error" and the "you sent me wierd data" - but I could live with separate faults 20:43:37 Geoff: I like having the disctinction 20:43:55 Bob: one is "I'm sick" and the other is "I don't understand your jive" 20:44:07 ack gpi 20:44:41 q+ 20:45:00 actually, it is 'I don't like your jive'! 20:46:53 Gil: (blathers on about something - basically agrees with Geoff but thinks fault shouldn't be overly specific) 20:47:13 Geoff: how far do we support people that don't use WS-Policy 20:48:31 q+ 20:48:31 Bob (as geek not chair): there is an old technique where I try to create a connection 20:48:57 ... I usually start with my most preferred alternative (full duplex, 56K/sec) 20:49:11 .. and I gradually back off through my prefered alternatives 20:49:34 ... the only thing you need is some way of determining if the connection is successful 20:49:37 q+ 20:50:08 ... w/regards to the multiplicity of extensions, etc. you can use multiple NotifyTo's 20:50:50 Geoff: sounds like you are saying "specify the fault and be done with it" 20:51:07 ack wu 20:51:10 Bob: point is that the client may never see the fault, but it needs to know if the Subscribe succeeded 20:51:25 Wu: "jive fault" should be grounding 20:51:33 Bob: anybody object to "jive fault" 20:51:46 DaveS: I'll make my comment, then answer 20:52:39 Wu: whether you "use Policy" (to decorate WSDL) or not, you should use this fault 20:52:45 ... this is another grounding point 20:53:01 ... we could also allow, optionally, in the fault message, the allowed alternatives 20:53:24 Geoff: what would that format look like, Policy? 20:53:27 q+ to spit the dummy on optional detail element content 20:53:53 Wu: up to the event source what the format of the detail is 20:53:58 ack dave 20:54:17 DaveS: I think I'm ok with "I'm sick" and "I don't understand your jive" as separate faults 20:54:32 ... but we shouldn't drill down to far on the "I don't understand your jive" fault 20:55:04 ... (???) has 12 different faults that all describe variations of "I don't understand your jive" 20:55:20 q+ 20:55:27 acl gpi 20:55:40 s/acl/ack 20:55:45 ack gil 20:55:51 ack gpi 20:56:43 ack bob 20:56:43 Bob, you wanted to spit the dummy on optional detail element content 20:56:54 Gil: cautions against optimizing for the case of detecting incompatible extensions 20:57:21 Bob (as geek): the point about optional detail on the jive fault is that it won't be processed by a machine 20:57:39 ... you can't count on it for negotiation because ultimately a human being is going to process it 20:57:56 ... and it might be expressed in a large number of ways 20:58:35 ... perfectly happy with "jive fault" and "sick fault" and leave it up to the impl what it in the detail 20:58:55 ... putting critical information in a fault that may never be received by the client seem foolhardy 20:59:06 ... my preference: 2 faults with impl-dependent details 20:59:28 ... if we still need something like a probing mechanism we can do that independently of the faulting mechanism 20:59:30 +1 to Bob's suggestion. 21:00:03 Bob: propose that "this" is how we deal with faulting extensions 21:00:44 Doug: (clarifies) two faults: an "internal error" fault and an "there is something wrong with your request" fault 21:00:53 Geoff: (further clarifies) 21:01:42 proposed resolution: 21:01:43 AI: Bob to write a proposal the codifies the above 21:03:02 There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicates subscribeRequestInvalid 21:03:21 the detail elements of both of these fault would be implementation dependent 21:03:42 both faullts are "generated" and not necessarilly "transmitted" 21:19:25 -Yves 21:21:31 [Detail] ? (Optional) 21:21:39 EventSourceUnableToProcess 21:22:33 q+ 21:22:50 ack geo 21:22:54 ack dug 21:23:42 q+ 21:25:21 q- 21:26:37 There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicatessubscribeRequestInva lid the detail elements of both of these fault would be implementation dependent 21:26:39 both faullts are "generated" and not necessarilly "transmitted". The element would be retained. 21:28:29 +Yves 21:29:49 There are two faults defined. The current fault that indicates internal error, and a fault that replaces the invalidmode fault that indicates subscribeRequestInvalid the detail elements of both of these fault would be implementation dependent both faullts are "generated" and not necessarilly "transmitted". The element would be retained. Text that describes the generation of... 21:29:51 ...these faults in the body of the spec will need to be adjusted accordingly. 21:31:27 RESOLUTION: Issue-7205 resolved with the proposal above 21:32:09 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206 21:32:20 Topic: Issue-7206 21:35:27 q+ 21:35:39 q+ 21:35:51 ack tom 21:36:25 ack dug 21:37:03 q+ 21:38:48 gpilz has joined #ws-ra 21:39:28 All: (discussion of above issue) 21:43:02 q+ 21:44:02 ack geo 21:46:12 Bob: WS-Eventing operates in accordance to the rules of the SOAP processing model 21:46:25 ... according to that model, extensions can be ignored 21:46:49 ... if is important for the service to understand it, you can use mU 21:47:10 ... you can use extensions w/out mU and you can use extensions to the response to indicate acceptance 21:47:38 ... non-understood mU will generate a fault 21:47:40 q+ 21:48:05 ... you have all the tools you need in this model to do what you need to do 21:48:19 ... one way to determine what is supported and what is not is to use mU to generate faults 21:48:35 All: very simple negotiation 21:48:59 Geoff: I'm not sure that is the actual problem 21:49:26 ... the problem is I can ignore things and you can't tell what I ignored and what I didn't ignore (for all those thing in which there was no mU) 21:49:52 q+ 21:50:17 Bob: the microbit that is not support according to the SOAP processing model is that I'd like to request an extens w/out mU but I'd like to know if it is ignored 21:50:46 Geoff: if I send Subscribe with NotifyTo and Pull and no mU headers, I need to understand what was enabled 21:51:01
  • q+ 21:51:29 ... it seems to be usefull to indicate which extensions were honored 21:53:04 ack wu 21:53:35 Wu: if I want to have an extension to Subscribe where I can either deliver to my office or my home 21:53:55 ... I need to know, in the Subscribe response, where the Notifications will be sent 21:54:01 ack gp 21:54:31 q- 21:54:36 What gil said. 21:56:05
  • q- 21:57:05 Gil: there is no issue here becase SubscribeResponse has an extension point that extension authors can use to indicate acceptance of/agreeement to the request extension(s) 21:57:49 Bob: need section in the primer on this subject: SubscribeRespone provides an extension point that (see above) 21:58:00 q+ to ask Wu a question 21:58:07 q+ 21:59:10 q- 21:59:19 ack asir 21:59:19 asir, you wanted to ask Wu a question 21:59:42 Asir: perhaps it would be easier to use your earlier example that . . . . 22:00:28 ... perhaps you and Gil are saying the same thing 22:00:33 Wu: (explain use case) 22:00:43 q+ 22:02:32 q+ 22:07:13 Wu: problem arises when you specify a choice of policy alternatives on Subscribe, you need to know which one was picked for that Subscription 22:07:38 Asir: you can use the extension point of SubscribeResponse to indicate which alternative was chosen 22:07:55 Wu: when you echo back, you have to attach this response to the Delivery element 22:08:12 Asir: you want a Delivery element on SubscribeResponse? 22:08:40 ... Wu wants a place to put the acknowledgement extension 22:09:14 ack dug 22:09:19 Doug: how closely tied is this issue to your other issues? 22:09:28 ... do you see something other than what Bob wants? 22:09:51 Wu: if you allow extension developers to pick QNames, it acts as an alternative to WS-Policy 22:10:11 Doug: let's say the Subscribe request can be extended by QNames (no Policy) 22:10:30 ... if we say that extension authors can use the xs:any of SubscribeResponse, is that ok? 22:10:33 Wu: in Delivery? 22:10:49 All: THERE IS NO DELIVERY ELEMENT IN SubscribeResponse 22:11:11 Doug: is this only need for the extensions-are-WS-Policy or in the general case? 22:11:16 Wu: general case 22:11:44 Doug: you are assuming that QName can appear either in Delivery and outside Delivery 22:12:21 ... so the semantics of inside and outside Delivery are so distinct that you need a Delivery element in SubscribeResponse to indicate that different things have been accepted 22:12:36 ... and it wouldn't be better just to use 2 different QNames? 22:13:38 Wu: (need Delivery element) 22:14:39 All: (general discussion ensues) 22:15:09 q? 22:16:18 ack wu 22:17:34 Bob: we put in the appropriate place (where we talk about extensions - 3.2) "extension authors are delegated the task of extending response message to indicate the understanding of and acceptance of the extension in the request" 22:17:49 q+ 22:18:12 is this the exact text or direction? 22:19:17 q+ 22:20:18 AI: Gil to write up proposal for above text 22:20:26 Doug: I want to put this everywhere 22:21:06 Bob: sprinkle on all specification liberally 22:21:13 ack dug 22:21:18 ack geo 22:21:18 Geoff: oh d*mn! 22:21:30 ... we have one element that we actually define "NotifyTo" 22:21:42 ... we have no "NotifyTo" in the SubscribeResponse 22:21:55 ... we probably need to define one? 22:21:59 Doug: don't think so 22:22:09 Bob: NotifyTo is our very first extension 22:22:58 All: (general discussion ensues) 22:25:10 ouch! 22:26:13 directional resolution agreed. 22:26:16 RESOLUTION: (directional) Gil to write up text (AI above) 22:49:03 TOPIC: issue 6642 22:50:57 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6642 22:55:55 q+ 22:58:49 ack asir 22:59:13 Asir: we need a way to address the explicit/implicit operation problem before we can talk about this 22:59:30 ... when a Subscriber subscribes he gets back a Subscription Manager EPR 22:59:57 ... there needs to be a way to get from the Subscription Manager EPR to the metadata that applies to the Subscription Manager 23:00:20 ... its up to the Event Source to use the "Metadata" bucket of the SubMgr EPR to include MEX 23:00:30 ... or you can use HTTP GET ....?wsdl 23:00:37 ... or pick up the phone 23:00:46 ... or perhaps a manual 23:01:13 Ashok: but you are telling us that this Subscription Manager is populated with its policy 23:01:18 Wu: that's an option 23:01:28 Ashok: once that occurs you can do whatever you want 23:02:01 ... I think you are telling us that the Subscription Manager has it's policy in EPR, and then you can access that somehow 23:02:07 ... yes 23:02:25 RESOLUTION: CWNA 23:05:47 TOPIC: issue 6694 23:06:44 Doug: (describes issue) 23:08:25 q+ 23:09:09 q+ 23:09:31 ack gp 23:09:42
  • q+ 23:11:21 q+ 23:11:35 ack asir 23:11:51 Asir: still trying to collect data to better understand the problem 23:12:53 ... Gil says it causes the unnecessary stubs 23:13:02 Gil: its not just stubs, it is the programming model 23:13:07 q+ 23:13:16 ack li 23:13:25 Li: I have a question for these implicit operations 23:14:09 ... implicit operations means if I have an application service that wants to use eventing or mex, by doing implicit operations I would hide the operations for eventing or mex from the application WSDL 23:14:23 ... the application service would not define the bindings for those operations 23:14:45 ... as a client, if I want to send a subscribe message, where do I get the binding 23:14:53 Asir: (reiterates) 23:15:13 Doug: look at how other specs to implicit specs like WS-RM 23:15:27 ... the binding is declared in the WSDL included in the WS-RM spec 23:15:41 Li: I think Asir understands me correctly 23:15:51 ... the client needs the whole WSDL to generate the code 23:15:59 ... at the same time the WSDL is hidden from the client 23:16:24 q+ 23:16:47 Doug: if operations are implicit there is no "client side" to be generated, it's part of the SOAP stack 23:17:17 Li: if I need to communicate to the service where the operation is hidden, I need to download a library? 23:17:43 -Yves 23:18:02 Gil: there is a WSDL for the client to look at - its in the spec 23:18:03 ack wu 23:18:07 q+ 23:18:08 Wu: I share these concerns 23:18:18 ... Eventing is very rich 23:18:41 ... I'm am concerned that, given all the optionality in Eventing, it can be used properly with implicit operations 23:18:48 ack asir 23:19:00
  • dug: you would need both client and server side intrastructure code to work 23:19:03 Asir: two concerns have been expressed 23:19:17 q+ 23:19:19 ... I would like to have a firm understanding of what is meant by implicit 23:19:22 ack gp 23:27:19
  • but authentication alglorithms have different strength 23:30:12 ack gpi 23:30:21 ack dug 23:31:06 Doug: depending upon what the policy assertion means, implicit behind that is a definition of the operations that will be supported by that endpoint 23:32:20 ... are there use cases in which the individual operations require separate policy? 23:32:36 ... even if there are, its not a given that you must make the operations explicit 23:32:38 q+ 23:33:06 ... there are other ways to relate policy to implicit operations that don't require making the operations explicit 23:33:10 ack asir 23:33:17 Asir: I haven't heard any new concerns 23:33:30 ... I understand this issue well enough for now 23:33:52 ... I suggest we think in pieces before we try and put it all together 23:34:02 ... one person is implementing an eventing stack 23:34:10 ... another is an eventing application programmer 23:36:42 ... (mentions WS-Trust as another example of an infrastructure spec) 23:40:02 All: (discussion ensues) 23:40:03 q? 23:41:18 q+ 23:41:48
  • q+ 23:42:51 Wu: in this implicit scenario, how do I know what kind of Events will be omitted by the port? 23:43:32
  • q- 23:44:42 ack wu 23:45:21 Asir: presence of the wsem:Eventing policy indicates that you can do a MEX GetMetadata and retrieve either EventDescriptions or Notification WSDL 23:45:28 ack dug 23:46:02 Doug: I'm OK with everything being implicit 23:46:27 ... but if the solution for different QoS on different protocols (eventing, enum) is to split my endpoint up, I don't like it 23:47:11 ... if we want to support different QoS either at the spec level or for operations within the specs, I can't live with a solution that requires the implementer to split their port up 23:47:45 Asir: let's say you have another assertion for Transfer (E - for Eventing, T - for Transfer) 23:48:10 ... so you build a policy expression with two alternatives, E and a bunch of stuff and T and a bunch of stuff 23:48:24 ... if you talk 'E' you get all the stuff that shares an alternative with E 23:48:39 ... if you talk 'T' you get all the stuff that shares an alternative with T 23:50:03 Doug: this still leaves the problem of per-operation policies within the same spec 23:56:36 q+ 23:56:54 ack dug 00:01:14 q+ 00:01:24 dug 00:02:27 ack dug 00:04:19
  • q+ 00:05:18 This WSDL describes the WS-MC protocol from the point of view of the endpoint that receives the MakeConnection message. 00:05:20 Also note that this WSDL is intended to describe the internal structure of the WS-MC protocol, and will not generally appear in a description of a WS-MC-capable Web service. See section 3.4 Policy for a higher-level mechanism to indicate that WS-MC is supported. 00:05:21 RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by sub-assertions or some other appropriate WS-Policy mechanism 00:06:09 q+ 00:06:27 jeffm has joined #ws-ra 00:06:37 ack li 00:07:43 q+ 00:08:11 ack asir 00:08:26 q+ 00:08:55 It is too narrow if every evening implementation must be implicit. 00:09:02 ack wu 00:09:08 there is no "MUST" in the above sentence 00:09:19 it says "will not generally appear" 00:09:27 This WSDL is intended to describe the internal structure of the XXX protocol, and will not generally appear in a description of a XXX capable Web service. See section xxx for a higher-level mechanism to indicate that XXX is supported. 00:09:40 q+ 00:10:07 q+ 00:10:09
  • we should not mandate everybody to hide implicit opreations, we give them choices 00:11:08 ack gpi 00:14:04 this is generally a blog/wiki/primer material 00:14:28 ack dug 00:14:57 q+ 00:15:20 ack asir 00:16:17 q- 00:16:40 q+ 00:18:34 ack jeff 00:19:15
  • q+ 00:21:20 ack li 00:22:27 RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by sub-assertions or some other appropriate WS-Policy mechanism 00:23:12 q+ 00:23:19 q+ 00:24:07
  • +1 wu 00:25:07 RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by assertions or some other appropriate WS-Policy mechanism. In addition the wsdl will be in the specs 00:25:43 It should be "If things are defined implicitly, it should be defined through WS-policy 00:30:16
  • +1 asir 00:31:54 If a WS-RA behavior is represented using one or more policy assertions, operations corresponding to the behavarior are implicitly defined. The WS-RA protocol specs will define WSDLs and XML Schemas. 00:32:11 This WSDL is intended to describe the internal structure of the XXX protocol, and MUST NOT appear in a description of a XXX capable Web service. See section xxx for a higher-level mechanism to indicate that XXX is supported. 00:34:54 RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by assertions or some other appropriate WS-Policy mechanism. In addition the wsdl will be in the specs 00:36:03 RESOLVED: motion carries 00:37:18 We are very concerned that "everything is implicitly defined with WS-Policy assertions" 00:37:39 rrsagent, generate minutes 00:37:39 I have made the request to generate http://www.w3.org/2009/08/05-ws-ra-minutes.html Bob 00:37:58 resolution carries 1 to lots 00:38:03 rrsagent, generate minutes 00:38:03 I have made the request to generate http://www.w3.org/2009/08/05-ws-ra-minutes.html Bob 00:41:02
  • msg geoff good luck! 00:41:48 -li 00:42:19 -[Microsoft] 00:42:20 WS_WSRA(F2F)11:30AM has ended 00:42:21 Attendees were [Microsoft], Yves, Vikas, li 00:54:20 gpilz has left #ws-ra