15:26:30 RRSAgent has joined #ws-ra 15:26:30 logging to http://www.w3.org/2009/06/09-ws-ra-irc 15:26:32 RRSAgent, make logs public 15:26:32 Zakim has joined #ws-ra 15:26:34 Zakim, this will be WSRA 15:26:34 ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start in 4 minutes 15:26:35 Meeting: Web Services Resource Access Working Group Teleconference 15:26:35 Date: 09 June 2009 15:28:17 WS_WSRA(3 day)11:30AM has now started 15:28:24 + +0125669aaaa 15:28:36 - +0125669aaaa 15:28:37 WS_WSRA(3 day)11:30AM has ended 15:28:37 Attendees were +0125669aaaa 15:33:31 Bob has joined #ws-ra 15:34:28 trackbot, start teleconference 15:34:30 RRSAgent, make logs public 15:34:32 Zakim, this will be WSRA 15:34:32 ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start 4 minutes ago 15:34:33 Meeting: Web Services Resource Access Working Group Teleconference 15:34:33 Date: 09 June 2009 15:34:46 dug has joined #ws-ra 15:34:59 Paul has joined #ws-ra 15:35:23 rrsagent, this meeting spans midnight 15:36:40 TomRutt has joined #ws-ra 15:50:16 trackbot has joined #ws-ra 15:55:10 WS_WSRA(3 day)11:30AM has now started 15:55:18 + +0207827aaaa 15:55:44 - +0207827aaaa 15:55:45 WS_WSRA(3 day)11:30AM has ended 15:55:45 Attendees were +0207827aaaa 15:56:55 Geoff has joined #ws-ra 15:57:10 WS_WSRA(3 day)11:30AM has now started 15:57:14 asir has joined #ws-ra 15:57:17 +??P1 15:58:38 prasad has joined #ws-ra 15:59:11 TomRutt has left #ws-ra 16:00:02 +Bob_Natale 16:01:00 TomRutt has joined #ws-ra 16:01:39 Scribe: Asir S Vedamuthu 16:01:42 ScribeNick: Asir 16:01:45 +Prasad_Yendluri 16:02:03 Meeting: W3C WS-RA WG F2F, Redwood Shores, CA! 16:02:10 Chair: Bob Freund 16:03:09 zakim, who is making noise? 16:03:20 Bob, listening for 10 seconds I heard sound from the following: Oracle_Conference_Center (30%) 16:03:53 Topic: Agenda Bashing 16:04:25 -Prasad_Yendluri 16:04:29 Agenda is at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0023.html 16:04:29 Ram has joined #ws-ra 16:04:43 3-day meeting 16:04:50 +Prasad_Yendluri 16:05:09 Bob: calling for 6 volunteers for 6 different slots 16:05:11 jeffm has joined #ws-ra 16:05:34 ... there are 6 premium slots, calling for tenders 16:05:47 ... the first one is already gone 16:06:09 Prasad: prefers Wed PM 16:06:30 Vikas has joined #ws-ra 16:06:41 Tom: prefers Tue PM 16:06:46 Ashok: Wed AM 16:07:17 Yves has changed the topic to: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0023.html 16:07:58 + +1.703.860.aaaa 16:08:28 marklittle has joined #ws-ra 16:10:33 Jeff: met for 6 months, discussed the same issue several times, prefers voting 16:10:35 q+ 16:10:50 +Mark_Little 16:11:16 Bob: formed taskforces, F2F is the best time to discuss hard issues 16:12:10 + +0125660aabb 16:12:13 ack asir 16:13:54 Ashok has joined #ws-ra 16:14:19 Asir: agree with Bob, we should try and build consensus to the best extent possible, we should build industry consensus not just within this group 16:14:31 ... it is important that carry the WG to see adoption 16:14:45 ... it is important taht we carry industry consensus to see adoption 16:15:04 ... would prefer that we don't get into any premature voting doldrums 16:15:17 Bob: points out the dependencies in the charter 16:16:31 ... featured issue of the day is 'mode' 16:16:48 ... featured issue for tomorrow is 6413 16:17:32 Asir: will we discuss FO? 16:17:42 Bob: will discuss on day 3 16:18:00 Jeff: WG does not discuss FO, sent to the Director 16:18:02 please add to the log mr. scribe: jeff asked how many many more weeks and months do we have to talk and "try to build consensus" before it is time to actually take a decsion and vote 16:18:25 Yves: WG should try and dispose formal objections 16:18:51 I would like to echo what Yves mentioned. We shoudl try and avoid formal objections 16:19:16 Bob: keep the discussion on tech merits and professsional 16:19:23 so don't file them when u lose on an issue, 16:19:41 We should work towards avoiding any such formal objections ... 16:19:56 Topic: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0023.html 16:20:12 Topic: Approval of minutes from the 2009-06-02 distributed meeting 16:20:26 Resolution: 2009-06-02 minutes approved 16:20:56 Topic: Task Team Progress 16:21:13 Gil is ready to discuss 6401 16:21:33 Bob: ready to discuss mode proposals 16:21:35 Yes 16:22:00 Bob: ready to discuss T and Frags issue 16:22:30 Topic: Issue-6956 Enum: server behavior after end of enumeration context 16:22:33
  • li has joined #ws-ra 16:22:42 See http://www.w3.org/Bugs/Public/show_bug.cgi?id=6956 16:23:11 postponed 16:23:24 Topic: Issue 6924 Transfer: behavior unspecified for Put 16:23:24 + +1.908.696.aacc 16:24:17
  • aacc is li 16:24:38 q+ 16:24:48 Gil is walks through his high-level proposal 16:24:57 s/is walks/walks/ 16:25:13 Gil: wants to clarify invalid rep fault 16:25:20 ack geo 16:25:53 Geoff: there are 3 cases in which Put should be disallowed 16:26:05 q+ 16:26:22 ... 1. Should PUT be disallowed entirely in this case 16:26:55 ack dug 16:26:56 ... 2. Should the client be able to send a PUT that contains only the elements that can be updated (partial)? 16:27:35 ... 3. Should the client send the whole resource, with the read-only values same? 16:27:45 Yves: define a fault 16:28:05 Doug: define a fault and not specify the cases when it should be used 16:28:13 ... something wrong with the data 16:28:26 + +1.408.202.aadd 16:28:43 ack yves 16:28:55 Yves: in the case of partial PUT, use a PATCH like operation 16:28:58 q+ 16:29:40 ... perhaps, IFMATCH and ETAG style mechanism, similar to HTTP 16:30:03 ... this will clearly dilineate fragment style PUT operation 16:30:40 Doug: want to see a PATCH proposal 16:31:20 ACTION: Yves to open an issue to solve versioning and partial PUT in Transfer AND provide a proposal 16:31:20 Created ACTION-67 - Open an issue to solve versioning and partial PUT in Transfer AND provide a proposal [on Yves Lafon - due 2009-06-16]. 16:32:10 q+ 16:32:19 Asir: when you mentioned PATCH, are you thinking of a new operation for fragment PUT 16:32:21 ack asir 16:32:21 Yves: yes 16:32:24 ack dug 16:33:03 Doug: sounds like a fragment-like feature, nice to have feature for tomorrow's discussion 16:33:52 Yves: will prepare some material for tomorrow's discussion 16:34:14 Wu has joined #ws-ra 16:34:53 pop the stack 16:34:55 q+ 16:35:03 Topic: Issue-6956 Enum: server behavior after end of enumeration context 16:35:30 Geoff walk through the proposal 16:36:05 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6956 16:36:33 ack dug 16:36:55 Doug: SHOULD should be a MUST 16:37:00 ... in section 3.2 16:38:31 ... applies to both request and response 16:38:40 ... MUST fail and MUST generate 16:38:53 Geoff: not sure yet 16:39:38 Wu has joined #ws-ra 16:41:13 ... you have to look at the proposal in context, let's look at the spec 16:42:53 Ashok: have two options: send another end of sequence or send an invalid context. Why don't we say that? 16:42:57 q+ 16:43:31 Geoff: if it is going to gen then the system should gen an invalid context, sometimes the system may generate a perfectly valid message, end of seq 16:43:42 Doug: hurts, hurts 16:44:12 ... perhaps, we need to introduce more changes to cover what Geoff is asking for 16:45:33 Geoff: will re-work the proposal to include enum context as well 16:46:07 Action: Geoff to re-work the proposal for issue 6956, due tomorrow! 16:47:16 Could not create new action - please contact sysreq with the details of what happened. 16:47:16 Could not create new action - please contact sysreq with the details of what happened. 16:49:25 Bob: temporarily disposed 6924 and 6956 16:49:40 I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Yves 16:49:47 Topic: Issue-6975 WS-Transfer needs to define the term 'literal resource 16:50:01 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6975 16:50:07 Gil: not hard to do! 16:50:27 ... means XML as is 16:51:28 q+ 16:52:14 Bob: related to 6712 16:52:33 ... would a def for lit rep move forward 6712 16:52:44 s/6712/6712?/ 16:53:42 Geoff: IFF 6712 outcome is no dialect, then high-level def is sufficient 16:53:42 q+ 16:54:01 q- 16:54:12 ... IFF 6712 outcome is - use dialect, then lit rep should be clearly defined 16:54:29 - +1.408.202.aadd 16:54:48 Bob: should we record a dependency 16:54:59 s/dependency/dependency?/ 16:55:36 http://news.bbc.co.uk/2/hi/business/7490346.stm 16:56:18 http://www.guardian.co.uk/commentisfree/2009/may/22/pringles-potato-crisp 16:56:45 Action: Gil to provide a draft definition for lit rep, issue 6975 16:56:45 Sorry, couldn't find user - Gil 16:58:37 Topic: Issue-6712 Transfer: Create is ambiguous 16:58:45 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712 16:59:04 q+ 16:59:22 Doug: sent out a revised proposal 17:00:00 ack geoff 17:00:08 Geoff: two kinds of areas that are unclear 17:00:32 ... 1. concept of DB example, service acting like a DB, taking a stream, creating something in a DB 17:00:54 ? 17:00:59 q? 17:01:05 ... transfer spec does not, transfer talks about a resource, it is upto a resource to decide what to do 17:01:17 q+ 17:01:32 ... DB service, will deal with things as it always it used to 17:01:48 ... will take string, xml, instruction 17:02:02 ... it is upto the DB to figure out how to handle classes of things 17:02:13 q+ 17:02:18 q- 17:02:31 ... it is upto the DB to figure out different classes of things 17:02:56 ... as they say in Aus, Bob is your uncle! 17:04:12 ... it is upto the service to decide what to do 17:04:36 ... walks through an example, say an issue client 17:05:22 ... 2. it is not easy to define what is a literal rep 17:05:36 ... have not seen any answers to questions that I posted to the WG 17:05:53 ... walks through a priority rep example 17:07:02 ... so, no need to intro any new attributes 17:07:46 ... we could follow Bob's suggestion of using the term 'payload' 17:09:02 q? 17:09:07 q+ 17:09:19 ack dug 17:09:41 Dug: will go with the assumption: authors had some smarts and introduced instruction 17:09:50 ... moving to payload = removing functionality 17:10:12 ... service can figure out by letting client to indicate 17:10:23 ... but this is one-off and not interoperable 17:11:05 ... transfer does not have any mechanism to tell the client what is the shape of the resource 17:11:22 ... very simple to clear this ambiguity 17:11:28 q+ 17:11:29 ... not comfortable to remove the functionality 17:11:46 Bob: why did the authors not provide a mechanism to indicate 17:12:05 Doug: guessing 17:12:25 Gil: authors were on a schedule and did not have sufficient time to think thru 17:12:37 ack geo 17:12:41 ... is it instruction or is it literal 17:12:53 ... does the service need to be aware 17:12:56 q+ geoff 17:13:04 ack gpi 17:13:39 q+ 17:13:44 ... supports doug's proposal 17:14:24 Asir wants to point of that Transfer Member Submission says 17:14:26 "Implementations should provide metadata which describes the use of the representation and how it relates to the resource which is created, but such mechanisms are beyond the scope of this specification." 17:14:44 It is upto the service to tell the world what is the shape of a resource 17:15:03 q+ 17:15:29 Geoff: what is the actual interop scenario? 17:15:35 q+ 17:15:42 how come nothing I said got in the minutes? 17:15:51 Please add it Gil 17:16:15 the crux of this issue is dualities 17:16:23 Doug: service can tell the client to include a header 17:16:45 ... wants a transfer-level mechanism for a client to tell the diff 17:17:02 now my comments will get interspersed with Doug's 17:17:36 note to bob, de-tangle Gil and Dug here 17:18:01 sometimes you want the service to interpret the contents, sometimes you don't 17:18:09 Geoff: for the issue processing example, would you, as a client, have said the attribute is a resource or instruction? 17:18:51 neither the client nor the service is "the absolute master" 17:18:57 they need to interact 17:19:17 "isResource" is a means for the client to hint to the service what is intended 17:19:18 Doug: in the example, you are storing an example 17:19:21 ... it may not matter 17:19:28 obviously the service may or may not honor that hint 17:19:31 ... there is no ambiguity 17:20:13 ? 17:20:17 q? 17:20:24 finally, denigrating other peoples use cases is non-productive (unless a use case is non-implementable, etc.) 17:20:26 Doug: my proposal will not impact existing impl 17:20:30 ack geo 17:20:31 ... this is a fringe usecase 17:20:34 ack dug 17:21:14 ... default is the status quo 17:21:17 ack ashok 17:21:33 Ashok: you actually started with an attribute as an URI 17:21:47 ... URI gives you a bigger scope, different values (rather than binary 17:22:33 ... what did you change from URI to boolean? 17:22:33 jeffm has joined #ws-ra 17:23:21 q+ 17:24:50 Doug: wants to know if this is raw data or instruction 17:25:02 ack asir 17:28:07 Asir: transfer does not spell out any mechanism to tell the client what is the shape of a resource 17:28:27 ... [quoted material from the transfer spec] 17:28:32 HTTP+HEAD IMO gives the metadata the client needs 17:28:36 ack gpil 17:29:03 ... And the create operation says that the contents of the create operation are service specific 17:29:08 ... it could be many things 17:29:17 ... the spec talks about a few possibilities 17:29:27 ... why is an instruction treated specially? 17:29:40 ... all you need is an URI and service-specific contents 17:29:50 ... this is similar to HTTP specification 17:30:49 Yves: in HTTP, it is upto the server (implementation of a resource) to figure out what to do with the contents 17:31:26 ... and the implementation of a resource can vary in nano seconds 17:31:44 + +1.408.202.aaee 17:31:50 - +1.703.860.aaaa 17:43:49 Vikas has joined #ws-ra 17:48:10 q? 17:48:18 RESUMED 17:49:00 Bob: received a request from Hemal Shah to present his views on some of WS-RA issues 17:49:11 ... he is a member of the DMTF/WS-Man WG 17:50:21 Geoff has joined #ws-ra 17:50:27 Bob: walks through the principle of robustness 17:50:40 as are Bob, Doug, Tom, Jeff, and myself 17:50:51 (members of the WS-MAN WG) 17:51:11 ... if you are making a statement about modeling after something, we should be cognizant of how much of those underlying stuff are used 17:51:59 ... summarizing ... 17:52:07 ... we have this thing called transfer 17:52:15 ... we are talking about creation 17:52:20 ... want something to be created 17:52:43 ... it could be a lit rep, instruction or something else 17:52:48 ... authors didn't define any further 17:52:53 ... this means 17:53:12 ... disambiguation is totally out of the hands of the Transfer spec 17:53:36 ... it is upto some other specs to define what the rep or something else 17:53:59 ... if we go along the lines of let's annotate using a boolean to disambiguate 17:54:10 q+ 17:54:14 ... I am worried that we are narrowing our use to a smaller scope 17:54:26 ... just lit rep and instruction 17:54:50 ... or here is another language that i dev to provide instructions 17:55:09 ... if we were to get on the route then I am worried 17:55:26 Doug: now prefers a URI 17:55:51 q- 17:55:52 Bob: we are talking about a vague thing, contraining to any small set is premature 17:56:00 ... that leaves us with three alternatives 17:56:50 ... a) if you want to tag a content, we will give you one that is optional 17:57:08 b) nothing is necessary, these are service-specific, defer to services 17:58:38 ... c) Recommend other mechanisms to get metadata or providing a place holder for client-server negotiation 18:00:32 q+ 18:01:43 Bob: practically boils down to a and b 18:01:58 ack ram 18:02:14 Ram: noticed that there is a struggle between what belongs to the protocol versus app layer 18:02:36 q+ 18:02:39 ... what is sent by the client could be data, instruction or both 18:02:46 q+ 18:03:23 ... how am I going to negotiate with the service? 18:03:30 q+ 18:03:38 Ashok: perhaps, a negotiation mechanism 18:03:55 ack wu 18:04:11 Bob: may be some rough analogy to media type 18:04:21 q+ 18:05:06 Wu: there are umpteen possibilities, there is no reason for us to define these possibilities, I am more inclined to leave this to service-specific 18:05:27 Wu - this isn't a new feature - the transfer spec already talks about doing this - we're just clearing up an ambiguity 18:05:45 q+ 18:05:46 Gil: we have an open thing here to define a policy for transfer, we don't need to know that now to decide on this issue 18:05:56 q- 18:06:27 ack gpi 18:06:32 q+ 18:06:40 ack ram 18:07:01 Ram: both parties seem to make good points, you don't know what the payload is going to be, range of values - data, instruction, both or something else 18:07:11 q+ 18:07:30 ... a proposal to indicate using a mechanism 18:08:14 ack geo 18:08:37 ... why not specify in the spec that payload could be anything, state that anyone could define the payload, use extensions for servers to figure out the nature of the payload 18:09:37 Geoff: use some wording to articulate clearly in the spec would help 18:10:46 Doug: opinion, you are removing a feature 18:11:05 ack ashok 18:11:40 q+ 18:11:44 Ashok: adding only a attribute, you do not have to use it 18:11:55 ... optional attribute 18:12:00 ... HTTP is not a good example 18:12:27 ... people are constantly inventing new protocols rather than using HTTP 18:13:02 ack gpi 18:13:51 Gil: Ram said that app can extend, Doug mentioned that is an interop issue, Geoff said that we could clarify 18:13:55 ack geo 18:14:08 Geoff: you may say that the attribute is optional ... but it is not 18:14:19 ... not actually optional 18:14:47 ... if the client gets confused then this will confuse the client 18:14:58 ... what if I use it and what if I don't use it 18:15:03 ... this is the point that Wu mentioned 18:15:25 ... this is shifting the ball from service-specific to client-specific 18:15:33 q? 18:15:52 Bob wants to hear from Tom 18:16:05 Bob: can you argue for both sides 18:16:20 Tom: prefers strong typing, so prefers an extra flag 18:16:28 ... how can I defend for the other side 18:16:29 fmaciel has joined #ws-ra 18:16:38 ... it is upto the other side to figure out 18:17:18 s/other side/app side/ 18:17:21 DaveS has joined #ws-ra 18:17:24 Bob: there are two options 18:17:37 ... a) add an optional xs:anyURI 18:17:44 Wu has joined #ws-ra 18:18:11 + +1.408.970.aaff 18:18:15 - +1.408.202.aaee 18:18:17 ... b) close with no action 18:19:11 ... c) provide guidance to implementers on how to extend the protocol for indicating content 18:20:54 Ram: c) is all about setting expectations and providing guidance 18:21:05 q+ to ask for clarification 18:24:08 Asir: points out how to build consensus 18:24:42 Asir moves to delay with additional, undefined proposals 18:25:20 as far as consensus goes, I have not interest in an attribute that is "optional to understand" 18:25:23 Bob: what does a) mean? If I am the creator of the message, it would pass schema validation. If I were a receiver of it I could not understand, I could not support that URI 18:25:25 q+ 18:25:34 it totally undoes the intent of the original proposal 18:25:49 Bob: it is not ignorable 18:26:22 s/not ignorable/ 18:26:34 Bob's option a) is a hint that is ignorable 18:29:00 Bob is looking at one of Doug's proposal 18:31:17 fmaciel has joined #ws-ra 18:32:31 doug refers to the issue description for his original proposal 18:32:47 Folks on the phone - whiteboard discussion in-progress 18:37:49 Transcribing white board 18:38:09 a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION 18:38:16 b) Close with no action 18:40:28 Adding more stuff to option a) 18:41:58 a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service cares then faults if the URI is not known. If the service does not care about the hint, then ignrores 18:42:11 s/care about/need/ 18:47:31 restating option a) 18:49:12 a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate fault. If the service does not require a hint then may ignore the CONTENT DESCRIPTION. Type(CONTENT DESCRIPTION) = xs:anyURI 18:50:41 b) Close with no action 18:51:55 q+ 18:52:13 a) includes defining a fault 18:54:24 OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate fault. If the service does not need a hint then may ignore the CONTENT DESCRIPTION and will NOT generate a fault. Type(CONTENT DESCRIPTION) = xs:anyURI 18:55:42 re-stating 18:55:43 a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate a fault (to be defined). If the service does not need a hint then may ignore the CONTENT DESCRIPTION and MAY NOT generate a fault. Type(CONTENT DESCRIPTION) = xs:anyURI 18:56:08 b) Close with no action 18:56:48 Bob: a) is only a direction not a concrete proposal, editors will need to prep a concrete proposal 18:58:56 Paul has joined #ws-ra 18:59:03 RESOLUTION: consensus on a) as the directional proposal 18:59:35 Issue is still open 18:59:56 Action: Doug to prep a concrete proposal based on directional proposal a) for issue 6712 18:59:56 Created ACTION-68 - Prep a concrete proposal based on directional proposal a) for issue 6712 [on Doug Davis - due 2009-06-16]. 19:01:17 BobN has joined #ws-ra 19:01:47 -Mark_Little 19:02:20 -Bob_Natale 19:02:32 - +1.408.970.aaff 19:02:53 - +1.908.696.aacc 19:04:49 -Prasad_Yendluri 19:06:42 +??P0 19:21:18 http://www.w3.org/2002/ws/ra/edcopies/wst.html isn't working 19:43:34 scribin - ur doin it wrong 19:43:48 scribe: Tom Rutt 19:44:36 scribenick: TomRutt 19:52:52 q+ 19:56:14 + +1.408.970.aagg 19:56:37 Topic: Issue 6692 (Mode) 19:57:09 http://www.w3.org/2002/ws/ra/wiki/ 19:57:59 http://www.w3.org/2002/ws/ra/wiki/Proposals_for_6692 19:59:10 q? 19:59:19 ack asir 19:59:19 asir, you wanted to ask for clarification and to and to 19:59:53 q+ 20:00:19 Gil: I suggest that we are familiar with all the proposals, and suggest we move this to CHAD. Is there anyone whose opinion will change with further review of the proposals? 20:00:57 No support for Proposal A indicated 20:01:23 Some support for Proposal B 20:02:07 Some support for Proposal C 20:02:59 Some support for Proposal D 20:03:16 + +1.908.696.aahh 20:03:55 +Mark_Little 20:06:20 Bob: lets do a single vote per company STV. 20:06:54 q+ 20:07:25 q- 20:08:55 Proposal B. remove wse:Delivery element and all it's sub-elements Proposal C. close with no action Proposal D. Add new mode 20:10:59 q+ 20:11:11 ack geoff 20:11:23
  • zakim aahh is li 20:11:28 Bob: B handles policy centric world well, C does not service it, D provides a way to indicate use of policy. In terms of charter, C and D are stronger 20:12:00 - +0125660aabb 20:13:07 Geoff: Can we separate the proposals, remove delivery element, ws only remove mode attribute of delivery element? 20:13:11 Delivery element's purpose can be achieved using the EPR element instead. 20:14:32 Geoff: there has not been a lot of discussion on delivery item itself 20:14:33 There are things in Delivery that are not good for EPR, see examples 20:14:52 in Li's cases 20:15:05 those are properties of the subscription and would go outside of the Delivery element. 20:15:39 Geoff: delivery element allows for containment of life cycle 20:15:52 ack asir 20:16:29 And Li's example is a perfect example of the problem with Mode. How do you compose those two new modes with your Proxy example? Who will define those new modes? 20:16:54 Asis: It seems premature to stop working for consensus. Implementers have spoken, we need to consider their views for adoption purposes 20:17:00 s/Asis/Asir/ 20:17:21 Bob: can someone speak why D is not appropriate? 20:18:04 Dug: Proposal D does not do anything for interop or composability. Keeping Mode in any shape or fashion encourages bad behaviour. 20:18:43 Asir: I do not agree Mode is being used as a replacment for RM or Security. 20:20:27 Bob: Push with Ack in ws-man is not an adequate replacement for ws-rm, it is mainly a flow control mechanism. 20:20:49 Gil while is is not an adequate replacment for WS-RM there is a lot of functional overlap 20:21:10 s/is is/ mode push with ack is/ 20:21:21 q+ 20:21:27 q+ 20:21:33 + +0207827aaii 20:23:12 prasad has joined #ws-ra 20:23:52 Bob: I am concerned that Mode conflates characteristics of format, protocol behaviour, network characteristics and jumbles them into a single URI value 20:25:11 Bob: Dug's argument is that the Mode mechanism is not consistent with other extension mechanisms commonly used in ws-* specs 20:26:21 Bob: I am not hearing new concerns on the use of Mode. 20:29:19 Bob: my device implementers could accept an alternative which is a qname check, however if a policy intersection engine like thing is required, the would balk. 20:29:52 ?q 20:29:54 q? 20:30:04 s/ the would/ they would/ 20:30:39 bob: is eventing a device spec, a large system spec (possibliy incomfortable for devices) or for both? 20:31:21 Asis: I believe it has to work for both types of system 20:32:27 q? 20:32:50 Asir: I suggest we have a set of guidelines for the proper use of the Mode mechanism. We can have an example of one or two modes, to set the precident for the rest of the world to use. 20:33:20 Bob: I am not sure the big system guys would be happy unless there as a policy friendly approach to use 20:33:49 q+ 20:34:14 I also added that we should do it in a way that big system vendors adopts them too 20:34:43 Wu: option C does not disallow use of policy, however it maintains mode for small devices 20:35:22 Actually, option C composes with the use of WS-Policy 20:36:17 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html 20:36:20 ack wu 20:36:28 ack dug 20:37:24 if there is a perceived composition issue that should be addressed 20:37:30 no doubts 20:37:41 Dug: mode is a fundamentally broken feature, it not only does not compose with ws-* world, it also does not even work with its own suggested uses. Some of the examples (e.g., mode with proxy) do not work 20:38:35 There is clear value for a light solution in mode. And delivery element is critical seamtics in WS-E (See section 2.2) 20:39:06 Dug: what is missing is a way for event source to tell synch what it supports. A middle ground proposal is to give equivalent to mode, with a single uri check, but use a policy reference. 20:39:40 bob: the smallest device implementers will only support "push" mode. 20:40:20 Dug: we can define a mechanism to advertise which policy URIs are supported. This allows the best of both worlds. 20:41:15 Dug: a source can provide metadata to describe which policy can be placed within the subscribe. 20:41:40 Asir: it is qname not uri. 20:42:14 Dug: You could use a policy ref URI 20:43:16 Dug: mode is not extendable. You cannot add tweaks to an existing mode without creating a new mode URI. 20:43:48 ack geoff 20:45:16 q+ 20:46:09 ack ashok 20:46:11 Geoff: I recommend that we live with mode, and decide the best way to organize to move forward to give both sides what they need (not fracture market) 20:46:57 q+ 20:48:36 At smallest end they do not think of protocol, they implement a state machine which minimally ensures the protocol will work within their particular constraints. They want a simple qname, or URI attribute which they can do a comparison to. 20:48:57 s/At smallest/Bob: At smallest/ 20:50:06 Bob: On the other side, the system guys state mode is unacceptable. All behaviour is in extension specs, such as ws-man. You are not implementing eventing, but ws-man eventing. 20:50:38 Bob: this makes it difficult to extend in an incremental manner. 20:51:31 Bob: the small device guys want to know where to look for the value which they can do a quick check on. 20:51:43 ack yves 20:52:34 q+ 20:53:53 Yves: with regard to proposal D being "ugly". We have two user views, use policy, use a single value. Proposal D was not meant to be beautiful, but was meant to allow both user views. What is blocking factor in the use of proposal D? We have a wider community than WS-Man on both sides of these views 20:56:13 Dug: D promotes an extensibility point which is not useful in anything other than the simplest cases. I see it as fundamentally broken. Alllowing use of full blown policy or use of policy refs allows a solution which can work for the small and large systmes. 21:03:05 Bob: does example 1 of proposal b provide a mechanism for small system side? 1. This first one uses a PolicyReference to refer to a predefined policy assertion 21:03:18 Bob: is a policy ref uri a functional replacement for Mode? 21:04:33 Policy Reference URI does not carry any semantics 21:04:39 it is just a reference 21:06:02 Wu: I do not think so, since mode has defined fault messages. 21:06:10
  • q+ 21:06:13 bob: the fault is optional. 21:06:52 Gil: the fault as policy negotiaion at run time is way too late for me. There is a need to know ahead of time what is supported. 21:07:42 Wu: the policy reference does not satisfy the negotiation allowd by the mode with its faulting behaviour. 21:08:01 Dug: we could define a fault to use with the policy reference approach. 21:08:02 We are not convinced that policy reference URI is a functional replacement for mode 21:09:12 Dug: we can define a fault which is just as informative if the value of the policy reference URI is not acceptable, including the policy refs which are supported in the fault information 21:10:23 Bob: this approach is reducable to the minimal case for mode behaviour, but is extensible to more full use of policy. 21:12:33 Bob: we could state "resource constained systems should only use policy reference URI". 21:12:48 ack jeffm 21:12:58 ack wu 21:13:02 q- 21:13:07 ack geoff 21:13:33 I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Yves 21:15:16 q? 21:15:31 Geoff: By doing this we are missing the distinction of two life cycles by deleting delivery element.  You cannot stick everything you want into NotifyTo, you have lost differentiation. 21:15:36 q+ 21:16:53 Bob: back to the original question, can the policy ref (where it is placed can be discussed further) value serve as a functional equivalent to mode? 21:17:10 Geoff: this would require further discussion before answering. 21:19:00 Asir: while I agree a uri value can be used, it is a different question as to whether that uri can be a policy reference.  The policy ref is defined elsewhere. 21:20:34 Ashok: would you be happier with a policy expression being used rather than a policy ref? 21:21:15 Asir: that has concerns for the small device implementers. Also who would define the policy assertion for "push" 21:21:30 Ashok: this spec could define such a policy assertion type. 21:21:42 q/ 21:21:44 q? 21:22:04 Asir: that would require a complete proposal to evaluate. 21:22:36 Asir: using full policy expression would not help the small device implementers. 21:23:06 Ashok: the use of policy is not a problem, it seems to be the full policy intersection which is troublesome for implementers of small systems. 21:24:00 q? 21:24:15 ack li 21:26:58 Li: how about an option E: there are several modes listed in the Wiki. There is a hierarchy of things, push vs pull, then other features (ack or not), interval or not, and the combination may not be suitable for one uri. A compromise is to keep mode as element, and separate out the push vs pull indication. This would allow multiple refinements to do combinations. For those which do not support refinements, we still have push vs pull 21:27:56 bob: mode element with multiple possible children as refinement elements. One might be push, another ack. then push with acks would be adding both children. 21:28:33 Li: no I would prefere a mode element with name "push" allowing refinements such as "acks" or "intervals" 21:29:26 Bob: I see this as having some of the characteristics of ws-policy. 21:29:57 Gil: the ws world has ws-policy, which is a general purpose framework for dealing with such issues. Why do we need to have a concept of mode? 21:31:07 - +1.908.696.aahh 21:31:38 + +1.908.696.aajj 21:32:47 Gil: do not see need for additiona wrapper element, such as delivery, to deal with extensions. WS-man mode has functions which are outside of semantics of delivery element. The semantics of extension tell you what they are for, and can be kept as extension to subscribe element. 21:34:22 Bob: I hear Li’s proposal as a way to express the semantics of current uses of mode, using a mechanism which is similar to the policy expression.  21:36:28 bob: are you suggesting to put this new mode element within the deliver element, as an alternative to a mode attribute? 21:36:38 Li: yes that is my proposal. 21:39:36 Gil: given a nested structure, such as 21:39:38 Subscribe 21:39:40 Delivery 21:39:41 Mode 21:39:43 PolicyURI 21:39:44 NotifyTo 21:39:46 EndTo 21:39:48 Would a policy on notifyTo and EndTo require its own child policy like element. 21:42:46 Ashok has joined #ws-ra 21:43:36 Tom_Rutt has joined #ws-ra 21:43:48 test for tom 21:48:12 1 21:48:14 2 21:48:16 3 21:48:34 1 21:48:36 2 21:48:37 3 21:48:39 4 21:50:24 -Mark_Little 22:02:09 TomRutt has left #ws-ra 22:04:01 scribenic:Tom_Rutt 22:05:54 scribenick:Tom_Rutt 22:10:33 scribenick: Tom_Rutt 22:11:05 - +0207827aaii 22:11:25 q+ 22:12:09 Bob: the fundamental issue on mode as a single URI was regarding the combinatorial effect is helped by the list of behaviour elements, which makes it look more like the use of ws-policy 22:12:28 s/was regarding/, regarding/ 22:13:12 Bob: if we did have such a new "mode" element allowing a list of behaviour subElements, where would it be placed 22:14:20 Bob: I would like to understand why the delivery element would place this new mode element 22:15:36 Geoff: Mode as originally defined was to define lifecycle of notifications. If one was to replace mode with something like policy, this is a general concept which is broader than delivery aspects. 22:15:46 q+ 22:15:57 ack gpi 22:15:58 prasad has joined #ws-ra 22:16:52 Gil: extension is extension, with its own semantics. All we need is an any extension, which if not understood is ignored. You can also add a header element to indicate its use is required or in use. 22:16:56 ack dug 22:17:55 wsman:ContentEncoding, wsman:SendBookmarks both exist outside of wse:Delivery, yet apply to the lifecycle of the notifications 22:20:16 Dug: lifecycle of notification seems no different than lifecycle of any message. We already have an extension inside of EPR. both Notify To and End To have different semantics, but both could have a new feature which needs to be turned on. I see not need for having a new "endTo:@Mode" when epr extension could be used. 22:20:25 s/see not need/see no need/ 22:22:33 Dug: I see three extensions for: 22:22:35 Properties of notifications (notifyTo epr) 22:22:37 Properties of end to message (endTo epr) 22:22:39 Properties of subscription itself (xs any of subscribe) 22:25:12 dug: what do you need to do for a notification delivery that you do not have to do for end to and notify to 22:26:47 Dug: would it not be better to use a solution mechanism which can be used in other places for ws-* 22:28:55 Geoff: All the things which have been done with mode so far are eventing specific. I would have to think about (given eventing is one-way construct) mechanisms which are more general 22:31:19 Dug: the push vs pull example is concrete and might be a reason to keep mode. However we have ways to solve this without mode (e.g. make connection). RM has an acksTo epr which can work in push and pull environment without using something like the eventing delivery mode attribute 22:31:32 q? 22:33:39 Geoff: it is not clear to me that make connection is a complete solution for pull mode of eventing. It is the limitations of eventing that has me saying that the concept of doing eventing is different than just passing around messages 22:34:03 q+ 22:35:28 Dug: to keep mode there needs to be concrete examples as to why eventing is different. I need to understand why an EPR is not good enough to satisfy those needs. Most examples I have heard could be handled using an EPR. It seems to keep coming back to "that is the way we implemented it already" 22:37:00 ack wu 22:37:25 ack gpi 22:37:39 Wu: having a delivery mode attribute gives a single place to add delivery extensions. I do not see a problem of keeping mode, and also allowing more general policy mechanisms 22:38:43 q+ 22:39:01 BobN has joined #ws-ra 22:42:07 q+ 22:42:15 Gil: experience shows that people to not stay within the model of having delivery extension only be in the mode attribute. The idea that wse:delivery is a magical envelope to constrain all extensions does not work. For example, WS-Man has extensions that are not handled by delivery mode 22:44:32 Wu: I see value in delivery element, it is there and should not be removed 22:47:02 Dug: delivery does harm, since we have to explain how to use it and when to use it. We have to define what goes into subsribe, the delivery element, and the eprs. I see two extensibility points, say the subsribe and the notifyTo epr. Why is sending out notifications different than sending any other message. There are two lifecles, one for the subscription, the other for the message... 22:47:03 ...(notification). I don not see how we have an additional lifecycle between those two. 22:47:26 s/don not/do not/ 22:49:25 Dug: given structure 22:49:27 Subscribe 22:49:29 NotifyTo 22:49:30 … 22:49:32 EndTo 22:49:33 … 22:49:34
  • q+ 22:49:35 … 22:49:36 I see no need for anything between these two. NotifyTo gives all that is required for delivery. 22:50:22 Asir: if you take away push and pull this could be true 22:51:34 I am afraid that Doug wasn't around when Eventing was designed 22:51:55 Interesting rationale 22:52:08 Dug: eventing did not do a mode for endTo. 22:52:21
  • where is time machine? 22:52:32 Wu: that is because endTo has only push way. 22:52:40 q+ 22:52:40 i wish we had one .. so we could put doug in and roll him back 22:52:42 dug: why is push the only way to deliver endTo? 22:53:13 q+ 22:53:24 q-q- 22:53:25 ack dug 22:53:47 ack li 22:53:54 q- 22:54:51 Li: Dug says epr alone can indicate if I can do push or pull. What about anonymous address, this does not give enough information for push and pull. 22:55:44 Li: ws addressing has "anonymous" and "none" as address. 22:56:23 bob: Li is saying: with epr I can do push and pull mode with epr. How do I tell to do pull mode with EPR. I cannot send message to anonymous or none? How do I send pull message. 22:56:53 dug: you can pass in a makeConnection uri instead of an anonymous URI, that states the make connection is used to pull the message 22:57:58 q- 22:58:00 q+ 22:59:18 Li drives home the point that an EPR is not enough 22:59:43 Li: if you have to extend EPR why is it not acceptable to just use Mode, rather than define a new extension for epr? 23:01:12 Li now understands that the epr could be a container for more information 23:01:31 Geoff: If we put everything in an extension to notifyTo epr, I do not see how this could handle things such as queuing 23:02:29 Dug: priority mechanisms could apply to both push and pull. Those types of things would be properties of subscription, and thus would be outside notifyTo EPR. 23:03:51 Geoff: epr is to decide mechanism to send the information. However eventing has subscription mechanism to define how to send the information, not associated with mechanism used to send notification 23:06:22 Dug: we cannot remove extensibility inside the eprs, we need extensibility inside subscribe, I see not need for also having extensibility inside delivery element 23:10:23 q+ 23:11:38 Bob: regarding push and pull, we need a queuing mechanism for pull. If we need different qos for separate queues, this is not part of delivery but is part of the subscription. We could define a queuing behind a push (higher priority send first). It might be better to define in a general subscription bucket a way for defining extensions pertaining to the subscription. Some specs have put... 23:11:40 ...such extensions into the delivery mode, but they are not really associated with delivery endpoints 23:14:00 bob: having a flexible way to place extensibility points in different buckets seems good. Slicing the current aspects associate with current uses of mode into their more appropriate locations would be good. The concern seems to remain about evolution from current implementations. 23:16:10 asir has joined #ws-ra 23:17:15 Gil: putting policy in subscribe message itself is not how I see it. If I want to request that this subscription is pausable, I would put in an extension element for pause. Where policy comes in is for the event source to state whether it supports such an extension 23:21:19 Bob: If we use policy as general mechanism to govern operation of eventing for large systems, and retain the mode stuff for small systems, the large systems would not use such a mode extension unless they were implementing the specific spec which uses mode (e.g. ws-man) 23:23:23 Li: the mode could have an attribute at a high level (e.g, pull or push) Then its children could have more specific behaviour identifiers within the context of the higher level mode 23:27:39 Dug: 23:27:40 23:27:42 23:27:43 23:27:45 23:27:46 23:27:48 Why is this not good enough for such an extension 23:28:06 23:28:08 ... 23:28:09 23:28:11 23:28:12 23:29:26
  • should be inside ? 23:29:38 it can be - gil just moved it there :-) 23:29:53 gill: or could do: 23:29:55 23:29:57 23:29:58 23:30:00
  • ok, something like that 23:30:13 If queue is defined as part of pull extension 23:31:59 prasad has joined #ws-ra 23:32:00
  • or the root could be 23:36:09 Geoff: Gil’s proposal has always been: 1) use basic extensions to add new features, 2) use new headers to indicate support being understood, 3) use policy to advertise what is supported 23:37:57 s/support being/feature must be/ 23:40:10 q? 23:40:51 ack geo 23:40:56 ack asir 23:41:08 ack gpi 23:41:17 Dug: another example: 23:41:19 23:41:20 23:41:22 23:41:23 23:41:53 Dug: this is just as easy to check. The qname can be seached for in the subscribe message 23:44:20 Geoff: this approach allows many things to be added. How do you find the extensions 23:44:39 Dug: same problem exists for a mode element with multiple children 23:46:08 Gil there is nothing that can be done with a uri that cannot be done with a qName extension 23:48:43 q+ 23:49:26 q- 23:54:39 q+ 23:55:16 ack ram 23:55:31 jdurand has joined #ws-ra 23:55:53 q+ 23:58:26 as particpant rather than scribe: Any way to get around the combinatorial limitations of the mode attribute (such as Li’s proposal to allow a smaller number of high level mode names, e.g., push or pull, with a nested list of further detail elements, e.g, use ack) will require current ws eventing extensions to change their implantations to evolve. I am now even of the opinion that using the... 23:58:28 ... extensions with qNames will not be more difficult to implement than these other proposed hacks to retain the mode attribute 00:00:29 s/ implantations/implementations/ 00:00:30 q+ 00:00:44 s/ even of/even more of/ 00:01:05 ack ram 00:05:48 Gil: 00:05:50 00:05:52 (changed from 00:05:54 ? 00:05:55 ? 00:05:57 ? 00:05:59 00:06:00 00:06:02 why is this more difficult? 00:07:07 Bob: 00:07:08 00:07:10 (changed from 00:07:11 ? 00:07:13 ? 00:07:14 ? 00:07:16 00:07:18 00:08:20 Bob: we could define a predefined extension called mode with the proposal above 00:10:57 Bob: as an alternative could put the mode extension into the notifyTo EPR, or any other EPR you need to extend 00:11:12 Bob: currently there is no way to describe mode for endTo 00:11:42 q+ 00:12:39 q- 00:12:47 ack ram 00:16:05 q+ 00:21:06
  • it didn't die but was murdered 00:21:32 rsagent, generate mintes 00:21:37 it couldn't live with its own lameness 00:22:10 rrsagent, generate minutes 00:22:10 I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Bob 00:23:01 gpilz has left #ws-ra 00:24:48 recessed until tomorrow 00:24:53 rrsagent, generate minutes 00:24:53 I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Bob 00:25:36 - +1.408.970.aagg 00:25:37 -prasad 00:25:38 - +1.908.696.aajj 00:26:12 ashok tomorrow am, Prasad tomorrow pm 00:27:04 ashok tomorrow am, Prasad tomorrow pm 00:27:10 rrsagent, generate minutes 00:27:10 I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Bob 00:40:28 -Oracle_Conference_Center 00:40:30 WS_WSRA(3 day)11:30AM has ended 00:40:31 Attendees were Bob, Geoff, Asir, Ram, Yves, Jeff, Gil, Dug, Bob_Natale, Prasad_Yendluri, Tom, +1.703.860.aaaa, Jacques, Mark_Little, +0125660aabb, +1.908.696.aacc, +1.408.202.aadd, 00:40:33 ... +1.408.202.aaee, +1.408.970.aaff, prasad, +1.408.970.aagg, +1.908.696.aahh, +0207827aaii, +1.908.696.aajj