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

Timestamps are in UTC.

15:26:30 [RRSAgent]
RRSAgent has joined #ws-ra
15:26:30 [RRSAgent]
logging to http://www.w3.org/2009/06/09-ws-ra-irc
15:26:32 [trackbot]
RRSAgent, make logs public
15:26:32 [Zakim]
Zakim has joined #ws-ra
15:26:34 [trackbot]
Zakim, this will be WSRA
15:26:34 [Zakim]
ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start in 4 minutes
15:26:35 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
15:26:35 [trackbot]
Date: 09 June 2009
15:28:17 [Zakim]
WS_WSRA(3 day)11:30AM has now started
15:28:24 [Zakim]
+ +0125669aaaa
15:28:36 [Zakim]
- +0125669aaaa
15:28:37 [Zakim]
WS_WSRA(3 day)11:30AM has ended
15:28:37 [Zakim]
Attendees were +0125669aaaa
15:33:31 [Bob]
Bob has joined #ws-ra
15:34:28 [Bob]
trackbot, start teleconference
15:34:30 [trackbot]
RRSAgent, make logs public
15:34:32 [trackbot]
Zakim, this will be WSRA
15:34:32 [Zakim]
ok, trackbot; I see WS_WSRA(3 day)11:30AM scheduled to start 4 minutes ago
15:34:33 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
15:34:33 [trackbot]
Date: 09 June 2009
15:34:46 [dug]
dug has joined #ws-ra
15:34:59 [Paul]
Paul has joined #ws-ra
15:35:23 [Bob]
rrsagent, this meeting spans midnight
15:36:40 [TomRutt]
TomRutt has joined #ws-ra
15:50:16 [trackbot]
trackbot has joined #ws-ra
15:55:10 [Zakim]
WS_WSRA(3 day)11:30AM has now started
15:55:18 [Zakim]
+ +0207827aaaa
15:55:44 [Zakim]
- +0207827aaaa
15:55:45 [Zakim]
WS_WSRA(3 day)11:30AM has ended
15:55:45 [Zakim]
Attendees were +0207827aaaa
15:56:55 [Geoff]
Geoff has joined #ws-ra
15:57:10 [Zakim]
WS_WSRA(3 day)11:30AM has now started
15:57:14 [asir]
asir has joined #ws-ra
15:57:17 [Zakim]
+??P1
15:58:38 [prasad]
prasad has joined #ws-ra
15:59:11 [TomRutt]
TomRutt has left #ws-ra
16:00:02 [Zakim]
+Bob_Natale
16:01:00 [TomRutt]
TomRutt has joined #ws-ra
16:01:39 [asir]
Scribe: Asir S Vedamuthu
16:01:42 [asir]
ScribeNick: Asir
16:01:45 [Zakim]
+Prasad_Yendluri
16:02:03 [asir]
Meeting: W3C WS-RA WG F2F, Redwood Shores, CA!
16:02:10 [asir]
Chair: Bob Freund
16:03:09 [Bob]
zakim, who is making noise?
16:03:20 [Zakim]
Bob, listening for 10 seconds I heard sound from the following: Oracle_Conference_Center (30%)
16:03:53 [asir]
Topic: Agenda Bashing
16:04:25 [Zakim]
-Prasad_Yendluri
16:04:29 [asir]
Agenda is at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0023.html
16:04:29 [Ram]
Ram has joined #ws-ra
16:04:43 [asir]
3-day meeting
16:04:50 [Zakim]
+Prasad_Yendluri
16:05:09 [asir]
Bob: calling for 6 volunteers for 6 different slots
16:05:11 [jeffm]
jeffm has joined #ws-ra
16:05:34 [asir]
... there are 6 premium slots, calling for tenders
16:05:47 [asir]
... the first one is already gone
16:06:09 [asir]
Prasad: prefers Wed PM
16:06:30 [Vikas]
Vikas has joined #ws-ra
16:06:41 [asir]
Tom: prefers Tue PM
16:06:46 [asir]
Ashok: Wed AM
16:07:17 [Yves]
Yves has changed the topic to: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0023.html
16:07:58 [Zakim]
+ +1.703.860.aaaa
16:08:28 [marklittle]
marklittle has joined #ws-ra
16:10:33 [asir]
Jeff: met for 6 months, discussed the same issue several times, prefers voting
16:10:35 [asir]
q+
16:10:50 [Zakim]
+Mark_Little
16:11:16 [asir]
Bob: formed taskforces, F2F is the best time to discuss hard issues
16:12:10 [Zakim]
+ +0125660aabb
16:12:13 [Bob]
ack asir
16:13:54 [Ashok]
Ashok has joined #ws-ra
16:14:19 [asir]
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 [asir]
... it is important that carry the WG to see adoption
16:14:45 [asir]
... it is important taht we carry industry consensus to see adoption
16:15:04 [asir]
... would prefer that we don't get into any premature voting doldrums
16:15:17 [asir]
Bob: points out the dependencies in the charter
16:16:31 [asir]
... featured issue of the day is 'mode'
16:16:48 [asir]
... featured issue for tomorrow is 6413
16:17:32 [asir]
Asir: will we discuss FO?
16:17:42 [asir]
Bob: will discuss on day 3
16:18:00 [asir]
Jeff: WG does not discuss FO, sent to the Director
16:18:02 [jeffm]
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 [asir]
Yves: WG should try and dispose formal objections
16:18:51 [asir]
I would like to echo what Yves mentioned. We shoudl try and avoid formal objections
16:19:16 [asir]
Bob: keep the discussion on tech merits and professsional
16:19:23 [jeffm]
so don't file them when u lose on an issue,
16:19:41 [asir]
We should work towards avoiding any such formal objections ...
16:19:56 [asir]
Topic: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0023.html
16:20:12 [asir]
Topic: Approval of minutes from the 2009-06-02 distributed meeting
16:20:26 [asir]
Resolution: 2009-06-02 minutes approved
16:20:56 [asir]
Topic: Task Team Progress
16:21:13 [asir]
Gil is ready to discuss 6401
16:21:33 [asir]
Bob: ready to discuss mode proposals
16:21:35 [asir]
Yes
16:22:00 [asir]
Bob: ready to discuss T and Frags issue
16:22:30 [asir]
Topic: Issue-6956 Enum: server behavior after end of enumeration context
16:22:33 [li]
li has joined #ws-ra
16:22:42 [asir]
See http://www.w3.org/Bugs/Public/show_bug.cgi?id=6956
16:23:11 [asir]
postponed
16:23:24 [asir]
Topic: Issue 6924 Transfer: behavior unspecified for Put
16:23:24 [Zakim]
+ +1.908.696.aacc
16:24:17 [li]
aacc is li
16:24:38 [Geoff]
q+
16:24:48 [asir]
Gil is walks through his high-level proposal
16:24:57 [asir]
s/is walks/walks/
16:25:13 [asir]
Gil: wants to clarify invalid rep fault
16:25:20 [Bob]
ack geo
16:25:53 [asir]
Geoff: there are 3 cases in which Put should be disallowed
16:26:05 [dug]
q+
16:26:22 [asir]
... 1. Should PUT be disallowed entirely in this case
16:26:55 [Bob]
ack dug
16:26:56 [asir]
... 2. Should the client be able to send a PUT that contains only the elements that can be updated (partial)?
16:27:35 [asir]
... 3. Should the client send the whole resource, with the read-only values same?
16:27:45 [asir]
Yves: define a fault
16:28:05 [asir]
Doug: define a fault and not specify the cases when it should be used
16:28:13 [asir]
... something wrong with the data
16:28:26 [Zakim]
+ +1.408.202.aadd
16:28:43 [Bob]
ack yves
16:28:55 [asir]
Yves: in the case of partial PUT, use a PATCH like operation
16:28:58 [asir]
q+
16:29:40 [asir]
... perhaps, IFMATCH and ETAG style mechanism, similar to HTTP
16:30:03 [asir]
... this will clearly dilineate fragment style PUT operation
16:30:40 [asir]
Doug: want to see a PATCH proposal
16:31:20 [asir]
ACTION: Yves to open an issue to solve versioning and partial PUT in Transfer AND provide a proposal
16:31:20 [trackbot]
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 [dug]
q+
16:32:19 [asir]
Asir: when you mentioned PATCH, are you thinking of a new operation for fragment PUT
16:32:21 [Bob]
ack asir
16:32:21 [asir]
Yves: yes
16:32:24 [Bob]
ack dug
16:33:03 [asir]
Doug: sounds like a fragment-like feature, nice to have feature for tomorrow's discussion
16:33:52 [asir]
Yves: will prepare some material for tomorrow's discussion
16:34:14 [Wu]
Wu has joined #ws-ra
16:34:53 [asir]
pop the stack
16:34:55 [dug]
q+
16:35:03 [asir]
Topic: Issue-6956 Enum: server behavior after end of enumeration context
16:35:30 [asir]
Geoff walk through the proposal
16:36:05 [gpilz]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6956
16:36:33 [Bob]
ack dug
16:36:55 [asir]
Doug: SHOULD should be a MUST
16:37:00 [asir]
... in section 3.2
16:38:31 [asir]
... applies to both request and response
16:38:40 [asir]
... MUST fail and MUST generate
16:38:53 [asir]
Geoff: not sure yet
16:39:38 [Wu]
Wu has joined #ws-ra
16:41:13 [asir]
... you have to look at the proposal in context, let's look at the spec
16:42:53 [asir]
Ashok: have two options: send another end of sequence or send an invalid context. Why don't we say that?
16:42:57 [dug]
q+
16:43:31 [asir]
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 [asir]
Doug: hurts, hurts
16:44:12 [asir]
... perhaps, we need to introduce more changes to cover what Geoff is asking for
16:45:33 [asir]
Geoff: will re-work the proposal to include enum context as well
16:46:07 [asir]
Action: Geoff to re-work the proposal for issue 6956, due tomorrow!
16:47:16 [trackbot]
Could not create new action - please contact sysreq with the details of what happened.
16:47:16 [trackbot]
Could not create new action - please contact sysreq with the details of what happened.
16:49:25 [asir]
Bob: temporarily disposed 6924 and 6956
16:49:40 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Yves
16:49:47 [asir]
Topic: Issue-6975 WS-Transfer needs to define the term 'literal resource
16:50:01 [asir]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6975
16:50:07 [asir]
Gil: not hard to do!
16:50:27 [asir]
... means XML as is
16:51:28 [Geoff]
q+
16:52:14 [asir]
Bob: related to 6712
16:52:33 [asir]
... would a def for lit rep move forward 6712
16:52:44 [asir]
s/6712/6712?/
16:53:42 [asir]
Geoff: IFF 6712 outcome is no dialect, then high-level def is sufficient
16:53:42 [gpilz]
q+
16:54:01 [dug]
q-
16:54:12 [asir]
... IFF 6712 outcome is - use dialect, then lit rep should be clearly defined
16:54:29 [Zakim]
- +1.408.202.aadd
16:54:48 [asir]
Bob: should we record a dependency
16:54:59 [asir]
s/dependency/dependency?/
16:55:36 [jeffm]
http://news.bbc.co.uk/2/hi/business/7490346.stm
16:56:18 [jeffm]
http://www.guardian.co.uk/commentisfree/2009/may/22/pringles-potato-crisp
16:56:45 [asir]
Action: Gil to provide a draft definition for lit rep, issue 6975
16:56:45 [trackbot]
Sorry, couldn't find user - Gil
16:58:37 [asir]
Topic: Issue-6712 Transfer: Create is ambiguous
16:58:45 [asir]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712
16:59:04 [Geoff]
q+
16:59:22 [asir]
Doug: sent out a revised proposal
17:00:00 [Bob]
ack geoff
17:00:08 [asir]
Geoff: two kinds of areas that are unclear
17:00:32 [asir]
... 1. concept of DB example, service acting like a DB, taking a stream, creating something in a DB
17:00:54 [gpilz]
?
17:00:59 [gpilz]
q?
17:01:05 [asir]
... transfer spec does not, transfer talks about a resource, it is upto a resource to decide what to do
17:01:17 [gpilz]
q+
17:01:32 [asir]
... DB service, will deal with things as it always it used to
17:01:48 [asir]
... will take string, xml, instruction
17:02:02 [asir]
... it is upto the DB to figure out how to handle classes of things
17:02:13 [dug]
q+
17:02:18 [gpilz]
q-
17:02:31 [asir]
... it is upto the DB to figure out different classes of things
17:02:56 [asir]
... as they say in Aus, Bob is your uncle!
17:04:12 [asir]
... it is upto the service to decide what to do
17:04:36 [asir]
... walks through an example, say an issue client
17:05:22 [asir]
... 2. it is not easy to define what is a literal rep
17:05:36 [asir]
... have not seen any answers to questions that I posted to the WG
17:05:53 [asir]
... walks through a priority rep example
17:07:02 [asir]
... so, no need to intro any new attributes
17:07:46 [asir]
... we could follow Bob's suggestion of using the term 'payload'
17:09:02 [gpilz]
q?
17:09:07 [gpilz]
q+
17:09:19 [Bob]
ack dug
17:09:41 [asir]
Dug: will go with the assumption: authors had some smarts and introduced instruction
17:09:50 [asir]
... moving to payload = removing functionality
17:10:12 [asir]
... service can figure out by letting client to indicate
17:10:23 [asir]
... but this is one-off and not interoperable
17:11:05 [asir]
... transfer does not have any mechanism to tell the client what is the shape of the resource
17:11:22 [asir]
... very simple to clear this ambiguity
17:11:28 [Geoff]
q+
17:11:29 [asir]
... not comfortable to remove the functionality
17:11:46 [asir]
Bob: why did the authors not provide a mechanism to indicate
17:12:05 [asir]
Doug: guessing
17:12:25 [asir]
Gil: authors were on a schedule and did not have sufficient time to think thru
17:12:37 [Bob]
ack geo
17:12:41 [asir]
... is it instruction or is it literal
17:12:53 [asir]
... does the service need to be aware
17:12:56 [Bob]
q+ geoff
17:13:04 [Bob]
ack gpi
17:13:39 [dug]
q+
17:13:44 [asir]
... supports doug's proposal
17:14:24 [asir]
Asir wants to point of that Transfer Member Submission says
17:14:26 [asir]
"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 [asir]
It is upto the service to tell the world what is the shape of a resource
17:15:03 [Ashok]
q+
17:15:29 [asir]
Geoff: what is the actual interop scenario?
17:15:35 [asir]
q+
17:15:42 [gpilz]
how come nothing I said got in the minutes?
17:15:51 [asir]
Please add it Gil
17:16:15 [gpilz]
the crux of this issue is dualities
17:16:23 [asir]
Doug: service can tell the client to include a header
17:16:45 [asir]
... wants a transfer-level mechanism for a client to tell the diff
17:17:02 [gpilz]
now my comments will get interspersed with Doug's
17:17:36 [Bob]
note to bob, de-tangle Gil and Dug here
17:18:01 [gpilz]
sometimes you want the service to interpret the contents, sometimes you don't
17:18:09 [asir]
Geoff: for the issue processing example, would you, as a client, have said the attribute is a resource or instruction?
17:18:51 [gpilz]
neither the client nor the service is "the absolute master"
17:18:57 [gpilz]
they need to interact
17:19:17 [gpilz]
"isResource" is a means for the client to hint to the service what is intended
17:19:18 [asir]
Doug: in the example, you are storing an example
17:19:21 [asir]
... it may not matter
17:19:28 [gpilz]
obviously the service may or may not honor that hint
17:19:31 [asir]
... there is no ambiguity
17:20:13 [Bob]
?
17:20:17 [Bob]
q?
17:20:24 [gpilz]
finally, denigrating other peoples use cases is non-productive (unless a use case is non-implementable, etc.)
17:20:26 [asir]
Doug: my proposal will not impact existing impl
17:20:30 [Bob]
ack geo
17:20:31 [asir]
... this is a fringe usecase
17:20:34 [Bob]
ack dug
17:21:14 [asir]
... default is the status quo
17:21:17 [Bob]
ack ashok
17:21:33 [asir]
Ashok: you actually started with an attribute as an URI
17:21:47 [asir]
... URI gives you a bigger scope, different values (rather than binary
17:22:33 [asir]
... what did you change from URI to boolean?
17:22:33 [jeffm]
jeffm has joined #ws-ra
17:23:21 [gpilz]
q+
17:24:50 [asir]
Doug: wants to know if this is raw data or instruction
17:25:02 [Bob]
ack asir
17:28:07 [asir]
Asir: transfer does not spell out any mechanism to tell the client what is the shape of a resource
17:28:27 [asir]
... [quoted material from the transfer spec]
17:28:32 [dug]
HTTP+HEAD IMO gives the metadata the client needs
17:28:36 [Bob]
ack gpil
17:29:03 [asir]
... And the create operation says that the contents of the create operation are service specific
17:29:08 [asir]
... it could be many things
17:29:17 [asir]
... the spec talks about a few possibilities
17:29:27 [asir]
... why is an instruction treated specially?
17:29:40 [asir]
... all you need is an URI and service-specific contents
17:29:50 [asir]
... this is similar to HTTP specification
17:30:49 [asir]
Yves: in HTTP, it is upto the server (implementation of a resource) to figure out what to do with the contents
17:31:26 [asir]
... and the implementation of a resource can vary in nano seconds
17:31:44 [Zakim]
+ +1.408.202.aaee
17:31:50 [Zakim]
- +1.703.860.aaaa
17:43:49 [Vikas]
Vikas has joined #ws-ra
17:48:10 [gpilz]
q?
17:48:18 [asir]
RESUMED
17:49:00 [asir]
Bob: received a request from Hemal Shah to present his views on some of WS-RA issues
17:49:11 [asir]
... he is a member of the DMTF/WS-Man WG
17:50:21 [Geoff]
Geoff has joined #ws-ra
17:50:27 [asir]
Bob: walks through the principle of robustness
17:50:40 [gpilz]
as are Bob, Doug, Tom, Jeff, and myself
17:50:51 [gpilz]
(members of the WS-MAN WG)
17:51:11 [asir]
... 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 [asir]
... summarizing ...
17:52:07 [asir]
... we have this thing called transfer
17:52:15 [asir]
... we are talking about creation
17:52:20 [asir]
... want something to be created
17:52:43 [asir]
... it could be a lit rep, instruction or something else
17:52:48 [asir]
... authors didn't define any further
17:52:53 [asir]
... this means
17:53:12 [asir]
... disambiguation is totally out of the hands of the Transfer spec
17:53:36 [asir]
... it is upto some other specs to define what the rep or something else
17:53:59 [asir]
... if we go along the lines of let's annotate using a boolean to disambiguate
17:54:10 [dug]
q+
17:54:14 [asir]
... I am worried that we are narrowing our use to a smaller scope
17:54:26 [asir]
... just lit rep and instruction
17:54:50 [asir]
... or here is another language that i dev to provide instructions
17:55:09 [asir]
... if we were to get on the route then I am worried
17:55:26 [asir]
Doug: now prefers a URI
17:55:51 [dug]
q-
17:55:52 [asir]
Bob: we are talking about a vague thing, contraining to any small set is premature
17:56:00 [asir]
... that leaves us with three alternatives
17:56:50 [asir]
... a) if you want to tag a content, we will give you one that is optional
17:57:08 [asir]
b) nothing is necessary, these are service-specific, defer to services
17:58:38 [asir]
... c) Recommend other mechanisms to get metadata or providing a place holder for client-server negotiation
18:00:32 [Ram]
q+
18:01:43 [asir]
Bob: practically boils down to a and b
18:01:58 [Bob]
ack ram
18:02:14 [asir]
Ram: noticed that there is a struggle between what belongs to the protocol versus app layer
18:02:36 [Wu]
q+
18:02:39 [asir]
... what is sent by the client could be data, instruction or both
18:02:46 [gpilz]
q+
18:03:23 [asir]
... how am I going to negotiate with the service?
18:03:30 [Ram]
q+
18:03:38 [asir]
Ashok: perhaps, a negotiation mechanism
18:03:55 [Bob]
ack wu
18:04:11 [asir]
Bob: may be some rough analogy to media type
18:04:21 [dug]
q+
18:05:06 [asir]
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 [dug]
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 [Geoff]
q+
18:05:46 [asir]
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 [dug]
q-
18:06:27 [Bob]
ack gpi
18:06:32 [Ashok]
q+
18:06:40 [Bob]
ack ram
18:07:01 [asir]
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 [gpilz]
q+
18:07:30 [asir]
... a proposal to indicate using a mechanism
18:08:14 [Bob]
ack geo
18:08:37 [asir]
... 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 [asir]
Geoff: use some wording to articulate clearly in the spec would help
18:10:46 [asir]
Doug: opinion, you are removing a feature
18:11:05 [Bob]
ack ashok
18:11:40 [Geoff]
q+
18:11:44 [asir]
Ashok: adding only a attribute, you do not have to use it
18:11:55 [asir]
... optional attribute
18:12:00 [asir]
... HTTP is not a good example
18:12:27 [asir]
... people are constantly inventing new protocols rather than using HTTP
18:13:02 [Bob]
ack gpi
18:13:51 [asir]
Gil: Ram said that app can extend, Doug mentioned that is an interop issue, Geoff said that we could clarify
18:13:55 [Bob]
ack geo
18:14:08 [asir]
Geoff: you may say that the attribute is optional ... but it is not
18:14:19 [asir]
... not actually optional
18:14:47 [asir]
... if the client gets confused then this will confuse the client
18:14:58 [asir]
... what if I use it and what if I don't use it
18:15:03 [asir]
... this is the point that Wu mentioned
18:15:25 [asir]
... this is shifting the ball from service-specific to client-specific
18:15:33 [gpilz]
q?
18:15:52 [asir]
Bob wants to hear from Tom
18:16:05 [asir]
Bob: can you argue for both sides
18:16:20 [asir]
Tom: prefers strong typing, so prefers an extra flag
18:16:28 [asir]
... how can I defend for the other side
18:16:29 [fmaciel]
fmaciel has joined #ws-ra
18:16:38 [asir]
... it is upto the other side to figure out
18:17:18 [asir]
s/other side/app side/
18:17:21 [DaveS]
DaveS has joined #ws-ra
18:17:24 [asir]
Bob: there are two options
18:17:37 [asir]
... a) add an optional xs:anyURI
18:17:44 [Wu]
Wu has joined #ws-ra
18:18:11 [Zakim]
+ +1.408.970.aaff
18:18:15 [Zakim]
- +1.408.202.aaee
18:18:17 [asir]
... b) close with no action
18:19:11 [asir]
... c) provide guidance to implementers on how to extend the protocol for indicating content
18:20:54 [asir]
Ram: c) is all about setting expectations and providing guidance
18:21:05 [asir]
q+ to ask for clarification
18:24:08 [asir]
Asir: points out how to build consensus
18:24:42 [gpilz]
Asir moves to delay with additional, undefined proposals
18:25:20 [gpilz]
as far as consensus goes, I have not interest in an attribute that is "optional to understand"
18:25:23 [asir]
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 [asir]
q+
18:25:34 [gpilz]
it totally undoes the intent of the original proposal
18:25:49 [asir]
Bob: it is not ignorable
18:26:22 [asir]
s/not ignorable/
18:26:34 [asir]
Bob's option a) is a hint that is ignorable
18:29:00 [asir]
Bob is looking at one of Doug's proposal
18:31:17 [fmaciel]
fmaciel has joined #ws-ra
18:32:31 [gpilz]
doug refers to the issue description for his original proposal
18:32:47 [asir]
Folks on the phone - whiteboard discussion in-progress
18:37:49 [asir]
Transcribing white board
18:38:09 [asir]
a) OPTIONAL Hint that describes the content, CONTENT DESCRIPTION
18:38:16 [asir]
b) Close with no action
18:40:28 [asir]
Adding more stuff to option a)
18:41:58 [asir]
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 [asir]
s/care about/need/
18:47:31 [asir]
restating option a)
18:49:12 [asir]
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 [asir]
b) Close with no action
18:51:55 [asir]
q+
18:52:13 [dug]
a) includes defining a fault
18:54:24 [asir]
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 [asir]
re-stating
18:55:43 [asir]
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 [asir]
b) Close with no action
18:56:48 [asir]
Bob: a) is only a direction not a concrete proposal, editors will need to prep a concrete proposal
18:58:56 [Paul]
Paul has joined #ws-ra
18:59:03 [asir]
RESOLUTION: consensus on a) as the directional proposal
18:59:35 [asir]
Issue is still open
18:59:56 [asir]
Action: Doug to prep a concrete proposal based on directional proposal a) for issue 6712
18:59:56 [trackbot]
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]
BobN has joined #ws-ra
19:01:47 [Zakim]
-Mark_Little
19:02:20 [Zakim]
-Bob_Natale
19:02:32 [Zakim]
- +1.408.970.aaff
19:02:53 [Zakim]
- +1.908.696.aacc
19:04:49 [Zakim]
-Prasad_Yendluri
19:06:42 [Zakim]
+??P0
19:21:18 [gpilz]
http://www.w3.org/2002/ws/ra/edcopies/wst.html isn't working
19:43:34 [gpilz]
scribin - ur doin it wrong
19:43:48 [Bob]
scribe: Tom Rutt
19:44:36 [Bob]
scribenick: TomRutt
19:52:52 [gpilz]
q+
19:56:14 [Zakim]
+ +1.408.970.aagg
19:56:37 [TomRutt]
Topic: Issue 6692 (Mode)
19:57:09 [Bob]
http://www.w3.org/2002/ws/ra/wiki/
19:57:59 [TomRutt]
http://www.w3.org/2002/ws/ra/wiki/Proposals_for_6692
19:59:10 [Bob]
q?
19:59:19 [Bob]
ack asir
19:59:19 [Zakim]
asir, you wanted to ask for clarification and to and to
19:59:53 [Geoff]
q+
20:00:19 [TomRutt]
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 [TomRutt]
No support for Proposal A indicated
20:01:23 [TomRutt]
Some support for Proposal B
20:02:07 [TomRutt]
Some support for Proposal C
20:02:59 [TomRutt]
Some support for Proposal D
20:03:16 [Zakim]
+ +1.908.696.aahh
20:03:55 [Zakim]
+Mark_Little
20:06:20 [TomRutt]
Bob: lets do a single vote per company STV.
20:06:54 [asir]
q+
20:07:25 [gpilz]
q-
20:08:55 [TomRutt]
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 [Wu]
q+
20:11:11 [Bob]
ack geoff
20:11:23 [li]
zakim aahh is li
20:11:28 [TomRutt]
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 [Zakim]
- +0125660aabb
20:13:07 [TomRutt]
Geoff: Can we separate the proposals, remove delivery element, ws only remove mode attribute of delivery element?
20:13:11 [dug]
Delivery element's purpose can be achieved using the EPR element instead.
20:14:32 [TomRutt]
Geoff: there has not been a lot of discussion on delivery item itself
20:14:33 [Wu]
There are things in Delivery that are not good for EPR, see examples
20:14:52 [Wu]
in Li's cases
20:15:05 [dug]
those are properties of the subscription and would go outside of the Delivery element.
20:15:39 [TomRutt]
Geoff: delivery element allows for containment of life cycle
20:15:52 [Bob]
ack asir
20:16:29 [dug]
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 [TomRutt]
Asis: It seems premature to stop working for consensus. Implementers have spoken, we need to consider their views for adoption purposes
20:17:00 [dug]
s/Asis/Asir/
20:17:21 [TomRutt]
Bob: can someone speak why D is not appropriate?
20:18:04 [TomRutt]
Dug: Proposal D does not do anything for interop or composability. Keeping Mode in any shape or fashion encourages bad behaviour.
20:18:43 [TomRutt]
Asir: I do not agree Mode is being used as a replacment for RM or Security.
20:20:27 [TomRutt]
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 [TomRutt]
Gil while is is not an adequate replacment for WS-RM there is a lot of functional overlap
20:21:10 [TomRutt]
s/is is/ mode push with ack is/
20:21:21 [dug]
q+
20:21:27 [Geoff]
q+
20:21:33 [Zakim]
+ +0207827aaii
20:23:12 [prasad]
prasad has joined #ws-ra
20:23:52 [TomRutt]
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 [TomRutt]
Bob: Dug's argument is that the Mode mechanism is not consistent with other extension mechanisms commonly used in ws-* specs
20:26:21 [TomRutt]
Bob: I am not hearing new concerns on the use of Mode.
20:29:19 [TomRutt]
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 [dug]
?q
20:29:54 [dug]
q?
20:30:04 [TomRutt]
s/ the would/ they would/
20:30:39 [TomRutt]
bob: is eventing a device spec, a large system spec (possibliy incomfortable for devices) or for both?
20:31:21 [TomRutt]
Asis: I believe it has to work for both types of system
20:32:27 [gpilz]
q?
20:32:50 [TomRutt]
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 [TomRutt]
Bob: I am not sure the big system guys would be happy unless there as a policy friendly approach to use
20:33:49 [Ashok]
q+
20:34:14 [asir]
I also added that we should do it in a way that big system vendors adopts them too
20:34:43 [TomRutt]
Wu: option C does not disallow use of policy, however it maintains mode for small devices
20:35:22 [asir]
Actually, option C composes with the use of WS-Policy
20:36:17 [dug]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html
20:36:20 [Bob]
ack wu
20:36:28 [Bob]
ack dug
20:37:24 [asir]
if there is a perceived composition issue that should be addressed
20:37:30 [asir]
no doubts
20:37:41 [TomRutt]
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 [Wu]
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 [TomRutt]
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 [TomRutt]
bob: the smallest device implementers will only support "push" mode.
20:40:20 [TomRutt]
Dug: we can define a mechanism to advertise which policy URIs are supported. This allows the best of both worlds.
20:41:15 [TomRutt]
Dug: a source can provide metadata to describe which policy can be placed within the subscribe.
20:41:40 [TomRutt]
Asir: it is qname not uri.
20:42:14 [TomRutt]
Dug: You could use a policy ref URI
20:43:16 [TomRutt]
Dug: mode is not extendable. You cannot add tweaks to an existing mode without creating a new mode URI.
20:43:48 [Bob]
ack geoff
20:45:16 [jeffm]
q+
20:46:09 [Bob]
ack ashok
20:46:11 [TomRutt]
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 [Wu]
q+
20:48:36 [TomRutt]
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 [TomRutt]
s/At smallest/Bob: At smallest/
20:50:06 [TomRutt]
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 [TomRutt]
Bob: this makes it difficult to extend in an incremental manner.
20:51:31 [TomRutt]
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 [Bob]
ack yves
20:52:34 [Geoff]
q+
20:53:53 [TomRutt]
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 [TomRutt]
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 [TomRutt]
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 [TomRutt]
Bob: is a policy ref uri a functional replacement for Mode?
21:04:33 [asir]
Policy Reference URI does not carry any semantics
21:04:39 [asir]
it is just a reference
21:06:02 [TomRutt]
Wu: I do not think so, since mode has defined fault messages.
21:06:10 [li]
q+
21:06:13 [TomRutt]
bob: the fault is optional.
21:06:52 [TomRutt]
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 [TomRutt]
Wu: the policy reference does not satisfy the negotiation allowd by the mode with its faulting behaviour.
21:08:01 [TomRutt]
Dug: we could define a fault to use with the policy reference approach.
21:08:02 [asir]
We are not convinced that policy reference URI is a functional replacement for mode
21:09:12 [TomRutt]
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 [TomRutt]
Bob: this approach is reducable to the minimal case for mode behaviour, but is extensible to more full use of policy.
21:12:33 [TomRutt]
Bob: we could state "resource constained systems should only use policy reference URI".
21:12:48 [Bob]
ack jeffm
21:12:58 [Bob]
ack wu
21:13:02 [Wu]
q-
21:13:07 [Bob]
ack geoff
21:13:33 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Yves
21:15:16 [gpilz]
q?
21:15:31 [TomRutt]
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 [gpilz]
q+
21:16:53 [TomRutt]
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 [TomRutt]
Geoff: this would require further discussion before answering.
21:19:00 [TomRutt]
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 [TomRutt]
Ashok: would you be happier with a policy expression being used rather than a policy ref?
21:21:15 [TomRutt]
Asir: that has concerns for the small device implementers. Also who would define the policy assertion for "push"
21:21:30 [TomRutt]
Ashok: this spec could define such a policy assertion type.
21:21:42 [gpilz]
q/
21:21:44 [gpilz]
q?
21:22:04 [TomRutt]
Asir: that would require a complete proposal to evaluate.
21:22:36 [TomRutt]
Asir: using full policy expression would not help the small device implementers.
21:23:06 [TomRutt]
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 [Bob]
q?
21:24:15 [Bob]
ack li
21:26:58 [TomRutt]
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 [TomRutt]
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 [TomRutt]
Li: no I would prefere a mode element with name "push" allowing refinements such as "acks" or "intervals"
21:29:26 [TomRutt]
Bob: I see this as having some of the characteristics of ws-policy.
21:29:57 [TomRutt]
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 [Zakim]
- +1.908.696.aahh
21:31:38 [Zakim]
+ +1.908.696.aajj
21:32:47 [TomRutt]
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 [TomRutt]
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 [TomRutt]
bob: are you suggesting to put this new mode element within the deliver element, as an alternative to a mode attribute?
21:36:38 [TomRutt]
Li: yes that is my proposal.
21:39:36 [dug]
Gil: given a nested structure, such as
21:39:38 [dug]
Subscribe
21:39:40 [dug]
Delivery
21:39:41 [dug]
Mode
21:39:43 [dug]
PolicyURI
21:39:44 [dug]
NotifyTo
21:39:46 [dug]
EndTo
21:39:48 [dug]
Would a policy on notifyTo and EndTo require its own child policy like element.
21:42:46 [Ashok]
Ashok has joined #ws-ra
21:43:36 [Tom_Rutt]
Tom_Rutt has joined #ws-ra
21:43:48 [dug]
test for tom
21:48:12 [dug]
1
21:48:14 [dug]
2
21:48:16 [dug]
3
21:48:34 [Tom_Rutt]
1
21:48:36 [Tom_Rutt]
2
21:48:37 [Tom_Rutt]
3
21:48:39 [Tom_Rutt]
4
21:50:24 [Zakim]
-Mark_Little
22:02:09 [TomRutt]
TomRutt has left #ws-ra
22:04:01 [Tom_Rutt]
scribenic:Tom_Rutt
22:05:54 [Tom_Rutt]
scribenick:Tom_Rutt
22:10:33 [Bob]
scribenick: Tom_Rutt
22:11:05 [Zakim]
- +0207827aaii
22:11:25 [dug]
q+
22:12:09 [Tom_Rutt]
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 [Tom_Rutt]
s/was regarding/, regarding/
22:13:12 [Tom_Rutt]
Bob: if we did have such a new "mode" element allowing a list of behaviour subElements, where would it be placed
22:14:20 [Tom_Rutt]
Bob: I would like to understand why the delivery element would place this new mode element
22:15:36 [Tom_Rutt]
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 [Wu]
q+
22:15:57 [Bob]
ack gpi
22:15:58 [prasad]
prasad has joined #ws-ra
22:16:52 [Tom_Rutt]
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 [Bob]
ack dug
22:17:55 [gpilz]
wsman:ContentEncoding, wsman:SendBookmarks both exist outside of wse:Delivery, yet apply to the lifecycle of the notifications
22:20:16 [Tom_Rutt]
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 [Tom_Rutt]
s/see not need/see no need/
22:22:33 [Tom_Rutt]
Dug: I see three extensions for:
22:22:35 [Tom_Rutt]
Properties of notifications (notifyTo epr)
22:22:37 [Tom_Rutt]
Properties of end to message (endTo epr)
22:22:39 [Tom_Rutt]
Properties of subscription itself (xs any of subscribe)
22:25:12 [Tom_Rutt]
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 [Tom_Rutt]
Dug: would it not be better to use a solution mechanism which can be used in other places for ws-*
22:28:55 [Tom_Rutt]
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 [Tom_Rutt]
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 [Bob]
q?
22:33:39 [Tom_Rutt]
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 [gpilz]
q+
22:35:28 [Tom_Rutt]
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 [Bob]
ack wu
22:37:25 [Bob]
ack gpi
22:37:39 [Tom_Rutt]
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 [dug]
q+
22:39:01 [BobN]
BobN has joined #ws-ra
22:42:07 [asir]
q+
22:42:15 [Tom_Rutt]
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 [Tom_Rutt]
Wu: I see value in delivery element, it is there and should not be removed
22:47:02 [Tom_Rutt]
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 [Tom_Rutt]
...(notification). I don not see how we have an additional lifecycle between those two.
22:47:26 [Tom_Rutt]
s/don not/do not/
22:49:25 [Tom_Rutt]
Dug: given structure
22:49:27 [Tom_Rutt]
Subscribe
22:49:29 [Tom_Rutt]
NotifyTo
22:49:30 [Tom_Rutt]
…
22:49:32 [Tom_Rutt]
EndTo
22:49:33 [Tom_Rutt]
…
22:49:34 [li]
q+
22:49:35 [Tom_Rutt]
…
22:49:36 [Tom_Rutt]
I see no need for anything between these two. NotifyTo gives all that is required for delivery.
22:50:22 [Tom_Rutt]
Asir: if you take away push and pull this could be true
22:51:34 [asir]
I am afraid that Doug wasn't around when Eventing was designed
22:51:55 [asir]
Interesting rationale
22:52:08 [Tom_Rutt]
Dug: eventing did not do a mode for endTo.
22:52:21 [li]
where is time machine?
22:52:32 [Tom_Rutt]
Wu: that is because endTo has only push way.
22:52:40 [Geoff]
q+
22:52:40 [asir]
i wish we had one .. so we could put doug in and roll him back
22:52:42 [Tom_Rutt]
dug: why is push the only way to deliver endTo?
22:53:13 [Bob]
q+
22:53:24 [dug]
q-q-
22:53:25 [Bob]
ack dug
22:53:47 [Bob]
ack li
22:53:54 [Bob]
q-
22:54:51 [Tom_Rutt]
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 [Tom_Rutt]
Li: ws addressing has "anonymous" and "none" as address.
22:56:23 [Tom_Rutt]
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 [Tom_Rutt]
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 [asir]
q-
22:58:00 [asir]
q+
22:59:18 [asir]
Li drives home the point that an EPR is not enough
22:59:43 [Tom_Rutt]
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 [Bob]
Li now understands that the epr could be a container for more information
23:01:31 [Tom_Rutt]
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 [Tom_Rutt]
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 [Tom_Rutt]
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 [Tom_Rutt]
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 [gpilz]
q+
23:11:38 [Tom_Rutt]
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 [Tom_Rutt]
...such extensions into the delivery mode, but they are not really associated with delivery endpoints
23:14:00 [Tom_Rutt]
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]
asir has joined #ws-ra
23:17:15 [Tom_Rutt]
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 [Tom_Rutt]
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 [Tom_Rutt]
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 [Tom_Rutt]
Dug:
23:27:40 [Tom_Rutt]
<subscribe>
23:27:42 [Tom_Rutt]
<notifyTo>
23:27:43 [Tom_Rutt]
</notifyTo>
23:27:45 [Tom_Rutt]
<Pull/>
23:27:46 [Tom_Rutt]
</Subscribe>
23:27:48 [Tom_Rutt]
Why is this not good enough for such an extension
23:28:06 [dug]
<subscribe>
23:28:08 [dug]
<notifyTo> ... </notifyTo>
23:28:09 [dug]
<pull/>
23:28:11 [dug]
<queue foo=true|false/>
23:28:12 [dug]
</subscribe>
23:29:26 [li]
should <queue> be inside <pull>?
23:29:38 [dug]
it can be - gil just moved it there :-)
23:29:53 [Tom_Rutt]
gill: or could do:
23:29:55 [Tom_Rutt]
<Pull>
23:29:57 [Tom_Rutt]
<Queue />
23:29:58 [Tom_Rutt]
</Pull>
23:30:00 [li]
ok, something like that
23:30:13 [Tom_Rutt]
If queue is defined as part of pull extension
23:31:59 [prasad]
prasad has joined #ws-ra
23:32:00 [li]
or the root could be <mode name="push|pull" >
23:36:09 [Tom_Rutt]
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 [Tom_Rutt]
s/support being/feature must be/
23:40:10 [Bob]
q?
23:40:51 [Bob]
ack geo
23:40:56 [Bob]
ack asir
23:41:08 [Bob]
ack gpi
23:41:17 [Tom_Rutt]
Dug: another example:
23:41:19 [Tom_Rutt]
<subscribe>
23:41:20 [Tom_Rutt]
<notifyTo> </notifyTo>
23:41:22 [Tom_Rutt]
<push_with-proxy/>
23:41:23 [Tom_Rutt]
</subscribe>
23:41:53 [Tom_Rutt]
Dug: this is just as easy to check. The qname can be seached for in the subscribe message
23:44:20 [Tom_Rutt]
Geoff: this approach allows many things to be added. How do you find the extensions
23:44:39 [Tom_Rutt]
Dug: same problem exists for a mode element with multiple children
23:46:08 [Tom_Rutt]
Gil there is nothing that can be done with a uri that cannot be done with a qName extension
23:48:43 [Ram]
q+
23:49:26 [Ram]
q-
23:54:39 [Ram]
q+
23:55:16 [Bob]
ack ram
23:55:31 [jdurand]
jdurand has joined #ws-ra
23:55:53 [Tom_Rutt]
q+
23:58:26 [Tom_Rutt]
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 [Tom_Rutt]
... extensions with qNames will not be more difficult to implement than these other proposed hacks to retain the mode attribute
00:00:29 [Tom_Rutt]
s/ implantations/implementations/
00:00:30 [Ram]
q+
00:00:44 [Tom_Rutt]
s/ even of/even more of/
00:01:05 [Bob]
ack ram
00:05:48 [Tom_Rutt]
Gil:
00:05:50 [Tom_Rutt]
<subscribe>
00:05:52 [Tom_Rutt]
<notifyTo> </notifyTo> (changed from <Delivery/>
00:05:54 [Tom_Rutt]
<endTo> </endTo>?
00:05:55 [Tom_Rutt]
<Filter/>?
00:05:57 [Tom_Rutt]
<Format/>?
00:05:59 [Tom_Rutt]
<Extension/>
00:06:00 [Tom_Rutt]
</subscribe>
00:06:02 [Tom_Rutt]
why is this more difficult?
00:07:07 [Tom_Rutt]
Bob:
00:07:08 [Tom_Rutt]
<subscribe>
00:07:10 [Tom_Rutt]
<notifyTo> </notifyTo> (changed from <Delivery/>
00:07:11 [Tom_Rutt]
<endTo> </endTo>?
00:07:13 [Tom_Rutt]
<Filter/>?
00:07:14 [Tom_Rutt]
<Format/>?
00:07:16 [Tom_Rutt]
<mode uri= />
00:07:18 [Tom_Rutt]
</subscribe>
00:08:20 [Tom_Rutt]
Bob: we could define a predefined extension called mode with the proposal above
00:10:57 [Tom_Rutt]
Bob: as an alternative could put the mode extension into the notifyTo EPR, or any other EPR you need to extend
00:11:12 [Tom_Rutt]
Bob: currently there is no way to describe mode for endTo
00:11:42 [Ram]
q+
00:12:39 [Tom_Rutt]
q-
00:12:47 [Bob]
ack ram
00:16:05 [asir]
q+
00:21:06 [li]
it didn't die but was murdered
00:21:32 [Bob]
rsagent, generate mintes
00:21:37 [gpilz]
it couldn't live with its own lameness
00:22:10 [Bob]
rrsagent, generate minutes
00:22:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Bob
00:23:01 [gpilz]
gpilz has left #ws-ra
00:24:48 [Bob]
recessed until tomorrow
00:24:53 [Bob]
rrsagent, generate minutes
00:24:53 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Bob
00:25:36 [Zakim]
- +1.408.970.aagg
00:25:37 [Zakim]
-prasad
00:25:38 [Zakim]
- +1.908.696.aajj
00:26:12 [Bob]
ashok tomorrow am, Prasad tomorrow pm
00:27:04 [Bob]
ashok tomorrow am, Prasad tomorrow pm
00:27:10 [Bob]
rrsagent, generate minutes
00:27:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/06/09-ws-ra-minutes.html Bob
00:40:28 [Zakim]
-Oracle_Conference_Center
00:40:30 [Zakim]
WS_WSRA(3 day)11:30AM has ended
00:40:31 [Zakim]
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 [Zakim]
... +1.408.202.aaee, +1.408.970.aaff, prasad, +1.408.970.aagg, +1.908.696.aahh, +0207827aaii, +1.908.696.aajj