IRC log of ws-ra on 2009-03-12
Timestamps are in UTC.
- 12:59:06 [RRSAgent]
- RRSAgent has joined #ws-ra
- 12:59:06 [RRSAgent]
- logging to http://www.w3.org/2009/03/12-ws-ra-irc
- 12:59:17 [Zakim]
- Zakim has joined #ws-ra
- 13:00:09 [Bob]
- meeting: WS-Resource Access face to face
- 13:00:20 [Bob]
- chair: Bob Freund
- 13:00:42 [Bob]
- we are getting organized...
- 13:00:47 [Yves]
- trackbot, start telcon
- 13:00:49 [trackbot]
- RRSAgent, make logs public
- 13:00:51 [trackbot]
- Zakim, this will be WSRA
- 13:00:51 [Zakim]
- ok, trackbot; I see WS_WSRA(F2F)9:00AM scheduled to start now
- 13:00:52 [trackbot]
- Meeting: Web Services Resource Access Working Group Teleconference
- 13:00:52 [trackbot]
- Date: 12 March 2009
- 13:01:11 [Yves]
- in another call, will dial as soon as it's finished
- 13:01:20 [Bob]
- ok
- 13:01:36 [li]
- li has joined #ws-ra
- 13:01:50 [Bob]
- agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0064.html
- 13:02:24 [Zakim]
- WS_WSRA(F2F)9:00AM has now started
- 13:02:31 [Zakim]
- +Li
- 13:04:35 [Zakim]
- +[IBM]
- 13:06:19 [dug]
- dug has joined #ws-ra
- 13:06:31 [Sreed]
- Sreed has joined #ws-ra
- 13:06:53 [Vikas]
- Vikas has joined #ws-ra
- 13:07:18 [Wu]
- Wu has joined #ws-ra
- 13:07:46 [DaveS]
- DaveS has joined #ws-ra
- 13:08:05 [Bob]
- scribe: Sreed
- 13:08:19 [Katy]
- Katy has joined #ws-ra
- 13:08:23 [Ashok]
- scribenick: Sreed
- 13:10:34 [TRutt]
- TRutt has joined #ws-ra
- 13:10:41 [Sreed]
- Bob: Discussion on the current agenda for today
- 13:11:21 [Sreed]
- Bob: Is the agenda acceptable?
- 13:11:26 [dug]
- add to agenda: discuss fpwd
- 13:11:46 [dug]
- add to agenda: discuss resolution of 6425
- 13:11:57 [gpilz]
- gpilz has joined #ws-ra
- 13:12:08 [Sreed]
- Bob: Agenda acceptable
- 13:13:00 [Sreed]
- Bob: Discussion on new issues
- 13:14:03 [Sreed]
- Bob: Any objection accepting all new issues
- 13:15:21 [Sreed]
- Topic: Doug first public working draft
- 13:17:01 [Sreed]
- TRutt: Process wise it is different
- 13:17:59 [Sreed]
- TRutt: Namespace list prefix in the exisiting schema
- 13:19:39 [Sreed]
- Bob: Implementation of resolution for 6425
- 13:19:45 [Bob]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425
- 13:21:09 [Sreed]
- Wu; Li any comment
- 13:21:35 [Sreed]
- TRutt: Editing of the new resolution for this issue
- 13:23:21 [Sreed]
- Bob: Changing "are sent" to "must be sent"
- 13:23:42 [Sreed]
- Bob: came up as Li proposal
- 13:23:53 [Bob]
- s/must/MUST
- 13:24:23 [Bob]
- Topic: Issue-6548
- 13:24:56 [Sreed]
- Bob: Disucss the issue 6548
- 13:25:06 [Sreed]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6548
- 13:25:08 [Bob]
- proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0061.html
- 13:26:07 [Sreed]
- Dug: Two cases to remove the references as discussed
- 13:26:33 [Sreed]
- Resolution: Proposal for 6548
- 13:27:14 [Bob]
- s/6548/6548 accepted
- 13:27:59 [Sreed]
- Topic: Issue-6577
- 13:28:09 [Sreed]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6577
- 13:29:09 [Sreed]
- Dug: outcome came up results to headers
- 13:29:28 [Sreed]
- Dug: Discussed about this issue
- 13:29:58 [Sreed]
- Dug: It may not be necessary for the coorrelation information
- 13:31:16 [Sreed]
- Dug: Consistency is good
- 13:31:24 [Bob]
- s/information/information is carried in wsa:relatesTo
- 13:32:30 [Zakim]
- +Yves
- 13:32:33 [Sreed]
- Dug: On request messages on response messages, there were different in the semantics
- 13:32:44 [Bob]
- Dug notes that responses do carry wsrt:ResourceTransfer and a fault is just a specialized response
- 13:35:45 [Sreed]
- Bob: Updated in the additional comments section
- 13:36:18 [Sreed]
- Resolution: Issue 6577 is closed with no action
- 13:36:45 [Bob]
- RT Faults have their own action uri, which indicates that it is an RT fault.
- 13:36:47 [Bob]
- Additional header is thus not necessary.
- 13:36:48 [Bob]
- CWNA
- 13:38:21 [Sreed]
- Topic: 6636
- 13:38:27 [Sreed]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6636
- 13:39:48 [Sreed]
- Dug: Have Jeff open up a separate issue
- 13:40:42 [Sreed]
- Bob: Post the proposed example
- 13:41:13 [Sreed]
- Bob: Two actions
- 13:41:56 [Bob]
- action: Doug to create an example for a representation of a resource after a create resource rel to Issue-6636
- 13:41:56 [trackbot]
- Created ACTION-46 - Create an example for a representation of a resource after a create resource rel to Issue-6636 [on Doug Davis - due 2009-03-19].
- 13:42:53 [Bob]
- action: Geoff to create a new issue that takes on the second part of Issue-6636
- 13:42:53 [trackbot]
- Created ACTION-47 - Create a new issue that takes on the second part of Issue-6636 [on Geoff Bullen - due 2009-03-19].
- 13:43:31 [Sreed]
- Bob: Updated in the additional comments section
- 13:44:55 [Bob]
- Issue to be divided
- 13:46:29 [Sreed]
- Topic: 6401
- 13:46:38 [Sreed]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401
- 13:47:21 [Sreed]
- Dug: Gil is working on this issue
- 13:49:02 [Sreed]
- Gil: Specific of this issue with the WS-I BP, BP says don't use notofication type operations in the port type defintion
- 13:49:19 [Sreed]
- DaveS: Why is it in-message only
- 13:49:58 [Sreed]
- TRutt: Notifications is one way only, event processing reviwed coming from the event source there is no expected response
- 13:50:44 [Wu]
- q+
- 13:50:57 [Sreed]
- Gi: Take port type and bind it to events source
- 13:51:19 [Sreed]
- TRutt: it is the WSDL output, what is the typical binding
- 13:51:33 [gpilz]
- q+
- 13:51:43 [Bob]
- ack wu
- 13:51:47 [Sreed]
- Wu: Event to subscriber how do you represent in the WSDL for concreate binding
- 13:52:13 [Sreed]
- Wu: Outbound operations, eventing stateful
- 13:52:32 [Sreed]
- Wu: Two choices one go through the BP
- 13:53:00 [Sreed]
- Wu: other choice to provide an interface in-only operation for the client
- 13:53:56 [Sreed]
- Wu: Interface of the subscriber will have an outbound operations specifying the interface in-only operation
- 13:54:03 [Sreed]
- DaveS: Event sync
- 13:54:50 [Sreed]
- DaveS: Simple solution define event sync which will have wrapper around it
- 13:54:57 [dug]
- q+
- 13:55:13 [Bob]
- ack gp
- 13:55:45 [Bob]
- gil suggests it is related to 6661
- 13:55:59 [Sreed]
- Gpliz: realted to the proposal to 6661 move apendix as it stands WS Eventing anything about the advertise
- 13:56:17 [Wu]
- q+
- 13:56:35 [TRutt]
- q+
- 13:56:46 [Sreed]
- Dug: Particular issue we all are on agreement, Gil is coming out the proposal
- 13:56:57 [Bob]
- ack dug
- 13:57:05 [Bob]
- ack wu
- 13:57:11 [Sreed]
- Wu: This is technical problem there is a way to address it
- 13:58:04 [Sreed]
- Gpliz: WS Eventing specificed output operations violates the BP
- 13:58:17 [Sreed]
- DaveS: 6641 for sure
- 13:58:32 [Sreed]
- Wu: This can be technically solved
- 13:59:08 [Sreed]
- Wu: BP compliance solution
- 13:59:09 [TRutt]
- q-
- 13:59:14 [li]
- q+
- 13:59:23 [Sreed]
- Bob: Updated in the Additional comments
- 13:59:49 [Sreed]
- TRutt: How do you do this in SOAP request
- 14:00:08 [Bob]
- ACTION: Gil with Wu and Dug to develop a proposal for the resolution of 6401 using input operations
- 14:00:08 [trackbot]
- Sorry, couldn't find user - Gil
- 14:00:22 [Bob]
- ACTION: Pilz with Wu and Dug to develop a proposal for the resolution of 6401 using input operations
- 14:00:25 [trackbot]
- Created ACTION-48 - With Wu and Dug to develop a proposal for the resolution of 6401 using input operations [on Gilbert Pilz - due 2009-03-19].
- 14:02:11 [Sreed]
- Topic: 6661
- 14:02:23 [Sreed]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
- 14:04:02 [Sreed]
- GPilz: Apendix is incomplete
- 14:04:44 [Sreed]
- gpliz: Incorrect - output only operations
- 14:04:52 [Sreed]
- gpliz: Woking on the proposal for this
- 14:05:46 [Sreed]
- gpliz: Eventing should provide complete solution
- 14:06:45 [dug]
- http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Metadata
- 14:06:55 [dug]
- q+
- 14:07:22 [Katy]
- q+
- 14:07:54 [Wu]
- q+
- 14:08:01 [Bob]
- ack dug
- 14:08:18 [Sreed]
- dug: Keep the apendix working group is looking at this
- 14:08:28 [Bob]
- ack li
- 14:09:04 [Sreed]
- li: can address for the solution speciifc to usecase (outbound solution)
- 14:09:28 [Bob]
- ack katy
- 14:10:01 [Sreed]
- Katy: Remove this shouldnt effect put another metadata solution
- 14:10:07 [Bob]
- ack wu
- 14:10:42 [Sreed]
- Wu: conclusion let us take a look
- 14:10:55 [Sreed]
- Bob: Are we agreement that is it broken
- 14:11:16 [Sreed]
- DaveS: Where in the spec are you referring
- 14:12:05 [Sreed]
- Ashok: Last line editior quote this is extension in subsequent version
- 14:13:19 [Sreed]
- gpilz: WS Eventing need to address this problem - correctly
- 14:14:00 [Sreed]
- Bob: No problem with agreeing the following needs to be siginificantly corrected or removed - editiorial action
- 14:14:47 [Sreed]
- DaveS: we still have an action 6641 to work & resolve
- 14:14:48 [Wu]
- q+
- 14:15:17 [dug]
- In this version of the specification the mechanism by which an event source advertises the notifications is still undefined but is being investigated.
- 14:15:28 [dug]
- q+
- 14:15:35 [Sreed]
- DaveS: it is the metadate exchange includes the policy we have plenty of work to do, this get the BP problem clear
- 14:15:40 [Bob]
- ack wu
- 14:15:52 [Sreed]
- Wu: Propose clear idea solution for 6641
- 14:16:13 [Sreed]
- gpliz: Oracle don't object to it
- 14:16:27 [Bob]
- Wu wishes to delay consideration until 6401 is resolved
- 14:16:43 [Bob]
- s/6641/6401
- 14:16:58 [dug]
- q?
- 14:17:40 [Sreed]
- gpliz: Apendix A is kind of wrong
- 14:18:12 [Bob]
- ack dug
- 14:18:12 [dug]
- In this version of the specification the mechanism by which an event source advertises the notifications is still undefined but is being investigated.
- 14:18:40 [Sreed]
- dug: we still need to look into this problem
- 14:19:03 [gpilz]
- ammend: we all agree that the current text in Appendix A is wrong - it is a disservice to our readers to leave it in there without some kind of warning
- 14:19:40 [Sreed]
- DaveS: we can wait
- 14:20:23 [Sreed]
- Ashok: work in progress
- 14:21:28 [Sreed]
- Bob: adding dependency for 6641
- 14:22:19 [dug]
- s/6641/6601/
- 14:22:58 [Bob]
- defer until consideraton of future proposal to 6401
- 14:23:08 [dug]
- s/6601/6401/
- 14:23:41 [Bob]
- replace the mumble above with Bob added a dependency in 6661 to 6401
- 14:24:25 [Sreed]
- Topic: 6432
- 14:24:40 [Sreed]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432
- 14:25:47 [Bob]
- sounds like
- 14:27:27 [Sreed]
- dug: Push means push/pull EPR Eventing system no changes, in Infrastrcture layer
- 14:27:48 [Sreed]
- DaveS: Client is in control in this situation
- 14:27:57 [Bob]
- q+
- 14:28:03 [Wu]
- q+
- 14:28:06 [Bob]
- ack bob
- 14:28:11 [Ashok]
- q+
- 14:28:55 [dug]
- q+
- 14:29:07 [gpilz]
- q+
- 14:29:39 [Sreed]
- Bob: respond to reviwer composing to make connection with specific example
- 14:29:56 [Sreed]
- Wu: I second to Bob comments
- 14:30:01 [Katy]
- q+
- 14:30:06 [Bob]
- ack wu
- 14:30:22 [TRutt]
- q+
- 14:30:33 [Sreed]
- Wu: works prefer to put an Appendix as how it supports - events can be extended to support
- 14:30:47 [Sreed]
- Wu: Major change in their implementations
- 14:30:49 [Bob]
- ack ashok
- 14:31:21 [Sreed]
- Ashok: Second mode - polling last 10 messages to be sent what would happen
- 14:31:51 [DaveS]
- q+
- 14:32:33 [Sreed]
- gpliz: make connection is any kind of EPR any kind of change to event source - WS Addressing, routing layer says it will put them in queue (messages)
- 14:32:59 [Sreed]
- gpliz: Event queue does the messages in FIFO
- 14:33:17 [Sreed]
- dug: First pull may not be notofication
- 14:34:01 [Sreed]
- gpliz: Entire system a "kind" of pull mechanisim event source of view kidn an asynchronus reponse message
- 14:34:14 [Wu]
- Wu: or put in the primer to illustrate how WS-E can support pull mode
- 14:34:22 [Vikas]
- Vikas has joined #ws-ra
- 14:35:21 [Sreed]
- gpliz: support make connection, how fast the notification generated, how many subscribers so need to support entire messages in the queue
- 14:36:14 [Sreed]
- Bob: it is not a poll mode it really handles the addressable client
- 14:36:44 [Katy]
- q-
- 14:37:29 [Bob]
- ack dug, gp
- 14:37:39 [Bob]
- ack dug
- 14:37:43 [Bob]
- ack gp
- 14:38:43 [Sreed]
- Dug: make connections is not mandate it is more logical to do it. Polling messages form Event source there is nothing says there could be throttle involved
- 14:38:57 [Sreed]
- dug: Message can be generated in this mode
- 14:39:11 [Sreed]
- dug: it is an implementation choice
- 14:39:29 [Sreed]
- dug: changes to spec rename to push to something else
- 14:39:41 [Sreed]
- dug: EPR based model
- 14:40:51 [TRutt]
- The suggestion of using make connection to get around the non addressable event listener, solves the NAT firewall problem. I understand that this does not provide a full Pull model, but we need to be sure that a full pull model is required before putting a solution into the standard. I could support the Make-connection approach to be an optional but normative conformance point for use with WS-eventing. I do not see issue 6432 as asking for full pull model
- 14:41:01 [Bob]
- ack tr
- 14:41:53 [gpilz]
- +1
- 14:42:25 [Bob]
- ack dave
- 14:42:55 [Sreed]
- DaveS: Pull point technology be a subsequent spec on top of this
- 14:43:26 [Sreed]
- DaveS: Subscription point needs to advertise make connection has its policy
- 14:43:40 [Sreed]
- DaveS: may be shows up in the spec
- 14:44:12 [Sreed]
- gpliz: we need issue address how the policy does this
- 14:44:58 [gpilz]
- q+
- 14:45:39 [Sreed]
- Bob: Make connection is a solution
- 14:46:10 [Bob]
- ack gpi
- 14:46:17 [Bob]
- ack gp
- 14:46:25 [Sreed]
- gpliz: I agree completely with TRutt said
- 14:46:33 [Bob]
- q?
- 14:46:38 [Bob]
- q+
- 14:46:41 [Bob]
- ack
- 14:46:44 [Bob]
- q-
- 14:46:45 [Wu]
- q+
- 14:47:25 [Sreed]
- gpliz:dug raised an good point - trying to get the notofications behind the firewall we recommend about the make-connection in the spec
- 14:47:27 [DaveS]
- q+
- 14:47:32 [Bob]
- ack wu
- 14:47:40 [dug]
- q+
- 14:47:58 [Bob]
- ack dave
- 14:48:11 [Sreed]
- DaveS: looking at spec itself
- 14:48:47 [Sreed]
- DaveS: Pull-model we do have URI subscription on this
- 14:49:26 [Sreed]
- DaveS: Client is concerned need to setup make connection, don't recognize the mode
- 14:49:55 [Sreed]
- gpliz: support make connection send me subscription back
- 14:51:18 [Sreed]
- dug: require expliclty pub/sub engine
- 14:52:36 [Bob]
- q?
- 14:53:13 [Bob]
- ack dug
- 15:08:11 [Sreed]
- Bob: Recommendation in spec is necessary
- 15:10:38 [Bob]
- s/necessary/necessary?
- 15:12:09 [dug]
- change ref from pull mode to delivery of events to non-addressable endpoints
- 15:13:44 [Bob]
- s/typically referred to as
- 15:13:46 [Bob]
- Pull mode/delivery of events to non-addressable endpoints
- 15:15:24 [Sreedh]
- Sreedh has joined #ws-ra
- 15:15:37 [Ashok]
- Bob: Proposal -- Replace 'push' with EPR-based'
- 15:16:14 [Sreedh]
- Bob: Section 3.3
- 15:16:59 [Sreedh]
- dug: making push mode, EPR mode will be default
- 15:17:07 [Sreedh]
- Wu: Keep push mode
- 15:17:45 [gpilz]
- q+
- 15:18:50 [li]
- q+
- 15:19:42 [Sreedh]
- Wu: Event to non-addressable
- 15:20:21 [Sreedh]
- dug: even though we use Push it will would specifiy addressable or non-addressable
- 15:20:33 [Sreedh]
- dug: recommended way to do that
- 15:20:33 [Bob]
- ack gp
- 15:20:46 [Sreedh]
- gpliz: problem with push mode it is more visible
- 15:21:14 [Katy]
- q+
- 15:21:18 [Sreedh]
- gpliz: do it with make connection on event sync side
- 15:21:34 [Sreedh]
- gpliz: lot of different ways in EPR
- 15:21:42 [Sreedh]
- gpliz: need to keep push
- 15:21:49 [Bob]
- ack li
- 15:22:12 [Ashok]
- How about "shove" :-)
- 15:22:19 [gpilz]
- need to mention that "push includes pushing to non-addressable EPRs via WS-MakeConnection"
- 15:22:23 [Bob]
- +1 to shove mode
- 15:22:25 [dug]
- LOL +1
- 15:23:14 [TRutt]
- q+
- 15:24:02 [DaveS]
- q+
- 15:24:18 [Bob]
- ack katy
- 15:24:39 [gpilz]
- q+
- 15:24:43 [Sreedh]
- Katy: Could we used distribute mode?
- 15:24:44 [Wu]
- q+
- 15:25:27 [Bob]
- ack tr
- 15:25:40 [Sreed]
- Sreed has joined #ws-ra
- 15:26:02 [li]
- push is event source initiated and implies timely delivery, these are not provided makeconnection
- 15:26:19 [Sreed]
- TRutt: Application invokation model from the sensibility I dont mind changing the name
- 15:26:30 [Bob]
- ack dave
- 15:27:17 [Sreed]
- DaveS: I looked through the spec all Push-mode references are URI, I can moe push-mode from the spec such as delivery give the EPR tells the source delivery of messages
- 15:27:25 [Ashok]
- scribenick: Sreedh
- 15:27:44 [Bob]
- scribenick: Sreed
- 15:28:58 [Sreed]
- gpilz: Event sycn uses make-connection two different views is an issue, should they both one mode or two mode
- 15:29:14 [Sreed]
- WS Eventing mention the use of make connection that should recommend that it should use it
- 15:29:59 [Sreed]
- gpliz: There is timing if I am adderssable sufficient pop-up listener now or later ie time/deliver mode
- 15:30:08 [li]
- push is defined in 3.3: A delivery mechanism where the source sends event messages to the sink as individual, unsolicited, asynchronous SOAP messages.
- 15:30:10 [Bob]
- q?
- 15:30:13 [dug]
- push could push events to a mailbox so timely is a bit ambiguous
- 15:30:15 [Bob]
- ack gp
- 15:30:18 [Sreed]
- gpliz: most efficient way
- 15:30:44 [Bob]
- ack wu
- 15:31:08 [Sreed]
- Wu: we should keep Push-mode atleast it is understood if there is new addition to this shouldn't create confusion
- 15:31:27 [Sreed]
- Wu: Need to have solution
- 15:31:35 [dug]
- q+
- 15:32:21 [Bob]
- Wu: add one sentence somewhere that mentions makeconnection
- 15:32:26 [Bob]
- ack dug
- 15:32:56 [Sreed]
- dug: need to make changes, also try to understand definition of push-mode
- 15:33:08 [Sreed]
- dug: we are not going further
- 15:33:26 [Sreed]
- Wu: Push-mode is applied to addressable EPR
- 15:33:32 [Sreed]
- Dug: why
- 15:34:02 [Sreed]
- Wu: notion of addressable EPR how it works
- 15:35:32 [Sreed]
- dug: we don't explain how to do push-mode
- 15:36:07 [Sreed]
- dug: how is this applicable to WS Addressing
- 15:36:21 [gpilz]
- q+
- 15:36:48 [Sreed]
- Bob: Dug & Wu need to work together on this
- 15:41:46 [gpilz]
- q+
- 15:42:31 [Bob]
- ack gp
- 15:45:58 [Sreed]
- Wu: there are many solutions are addressing these issues
- 15:46:23 [Sreed]
- Katy: why can't we specify this is recommended
- 15:48:15 [gpilz]
- recommend (1) to present as worthy of confidence, acceptance, use, etc.; commend; mention favorably: to recommend an applicant for a job; to recommend a book. (2) to represent or urge as advisable or expedient: to recommend caution. (3) to advise, as an alternative; suggest (a choice, course of action, etc.) as appropriate, beneficial, or the like: He recommended the blue-plate special. The doctor recommended special exercises for her. (4) to make desirable or att
- 15:51:37 [Bob]
- ACTION: Doug and Wu to work on a new proposal to resolve 6432
- 15:51:38 [trackbot]
- Created ACTION-49 - And Wu to work on a new proposal to resolve 6432 [on Doug Davis - due 2009-03-19].
- 15:58:19 [Sreed]
- Bob: Accepted 6691 & 6692
- 15:58:56 [Bob]
- s/2/2 as new issues
- 16:01:52 [Zakim]
- -Yves
- 16:02:01 [Zakim]
- -Li
- 16:17:31 [Bob]
- Bob has joined #ws-ra
- 16:47:01 [Ashok]
- Ashok has joined #ws-ra
- 16:50:39 [Bob]
- scribe: Ashok
- 16:51:09 [Ashok]
- Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403
- 16:51:19 [Ashok]
- scribenick: Ashok
- 16:51:37 [Bob]
- Topic: 6403 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0007.html
- 16:51:40 [Wu]
- Wu has joined #ws-ra
- 16:52:44 [Ashok]
- Dug: Create new section (don't need new namespace) with top-level-element which contains all the options you supprt
- 16:52:55 [Ashok]
- s/supprt/support/
- 16:53:12 [Ashok]
- ... pretty much focussing on filter dialect
- 16:53:42 [Ashok]
- ... Use namespace of filter dialect to specify dialect
- 16:54:02 [Ashok]
- ... can intersect policy using simple QName matching
- 16:54:23 [Katy]
- q+
- 16:55:04 [Ashok]
- Dug: Same template can be used for other specs
- 16:55:23 [Bob]
- ack katy
- 16:55:37 [Ashok]
- Katy: Will enum operations ever appear on WSDL
- 16:55:57 [DaveS]
- DaveS has joined #ws-ra
- 16:56:09 [Ashok]
- Dug: If implicit and required they do not appear on policy, if optional must appear on policy
- 16:57:58 [Ashok]
- Katy: In implict/optional case where policy is on endpoint we need policy to say what operations are supported and also the operations must support policy assertions
- 16:59:17 [Wu]
- Wu: Discussion issue 6403 about policy
- 17:00:10 [Ashok]
- Wu: Make it light!
- 17:00:32 [Katy]
- Katy: We also have the general problem of how we associate policy with these implicit operations. For example, how to associated security policy with the renew request.
- 17:01:13 [Katy]
- ... This could be done by nesting the policy for the implicit operations within the emumeration policy
- 17:01:25 [Katy]
- ... I will raise an issue to addres across specs
- 17:02:09 [Ashok]
- Action: Katy to create issue for policy issue for implicit operations
- 17:02:09 [trackbot]
- Created ACTION-50 - Create issue for policy issue for implicit operations [on Katy Warr - due 2009-03-19].
- 17:02:33 [Ashok]
- Wu: Need more time to consider
- 17:03:15 [Ashok]
- Dug: I'm happy to accept changes on this later
- 17:05:37 [Zakim]
- +Li
- 17:05:51 [Ashok]
- Bob: I have heard nothing about this issue for some time
- 17:06:28 [Bob]
- q?
- 17:07:27 [Ashok]
- Bob: I will give you week ... not on Tuesday's call but the follwing call
- 17:10:53 [Ashok]
- Topic: Issue 6632
- 17:11:16 [Ashok]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6632
- 17:11:45 [Ashok]
- Dug: This is a Transfer issue ... I would like to reassign to Transfer
- 17:12:39 [Yves]
- +1
- 17:14:09 [Zakim]
- +Yves
- 17:14:45 [Ashok]
- Bob: Any objection to reassigning this?
- 17:15:47 [Ashok]
- RESOLVED: Reassign to WS-T
- 17:17:22 [Ashok]
- Bob: General case of server being unable to provide response ... perhaps be just a general "cannot comply" fault
- 17:17:48 [jeffm]
- jeffm has joined #ws-ra
- 17:18:32 [Ashok]
- Topic: Issue 6633
- 17:19:01 [Ashok]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6633
- 17:20:22 [Ashok]
- Dug: This is a generic Transfer issue ... not only to fragments
- 17:20:49 [Ashok]
- DaveS: This big nightmare
- 17:21:03 [Ashok]
- s/bib//
- 17:21:11 [Ashok]
- s/big//
- 17:21:45 [Ashok]
- DaveS: Bigger problem in RT but applies to T as well
- 17:22:25 [Ashok]
- ... we need to answer in both places
- 17:23:11 [Ashok]
- Dug: If we move to T, RT would be able to leverage same solution
- 17:28:43 [Bob]
- entered into the isue comment:
- 17:28:47 [Bob]
- This seems to apply to both RT and T, may occur more frequently in RT, but both need resolution.
- 17:28:49 [Bob]
- It MAY be possible to find a repair in T that could be leveraged by RT.
- 17:28:50 [Bob]
- The issue related to xpath needs to be investigated and may need a new related issue resolution.
- 17:31:32 [Ashok]
- RESOLVED: Reassign to WS-T
- 17:32:20 [Ashok]
- ... can be caused when namespace not mentioned inside the body
- 17:33:33 [Ashok]
- Topic: Issue 6551
- 17:34:19 [Ashok]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6551
- 17:35:31 [Ashok]
- Dug: Can run out of time updating whole resource as well ... RT can piggyback on that fault
- 17:36:47 [Ashok]
- Katy: Transfer this to T and pull over RT fault
- 17:37:05 [DaveS]
- q+
- 17:38:07 [dug]
- q+
- 17:38:24 [Ashok]
- DaveS: Can fail with partial update
- 17:39:26 [Ashok]
- Bob: ACID criteria for updates?
- 17:40:47 [Ashok]
- Dug: Goeff has opoened another, related issue
- 17:41:08 [Ashok]
- ... lets transfer this and then discuss the other issue
- 17:42:43 [Bob]
- entered into comment:
- 17:42:47 [Bob]
- Processing time may be only one reason that the operation was unable to complete. Applies to T as well as RT, RT might leverage resolution in T.
- 17:42:48 [Bob]
- r-assign to T then re-visit
- 17:42:54 [Ashok]
- RESOLVED: Reassign to WS-T
- 17:43:25 [Ashok]
- Topic: Issue 6422
- 17:43:48 [Ashok]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6422
- 17:44:34 [Ashok]
- Dug: you can have same problem in WS-T world
- 17:44:52 [Ashok]
- ... applies to Transfer
- 17:45:12 [Ashok]
- DaveS: Or it does not apply if there is idempotency
- 17:46:08 [Yves]
- boxcarring to T makes no sense
- 17:49:34 [Yves]
- and what happens if there is a fault in the middle of processing all the changes to the same doc? rollback?
- 17:50:43 [Yves]
- so either you consider boxcarring as one operation (as Bob said), in that case boxcarring is application-specific and can be in a separate spec, or you plan to have a story about faults/rollback and it's getting messy
- 17:50:48 [Ashok]
- RESOLVED: Leave in RT but make sure RT follows T in terms of idempotency
- 17:52:01 [Bob]
- comment entered:
- 17:52:05 [Bob]
- Highlights that RT should follow idempotency properties of T, then might depend on specification of restrictions as to frags permitted
- 17:52:55 [Ashok]
- Bob: Shall we adjourn?
- 17:53:03 [Ashok]
- Adjourned
- 17:53:19 [Ashok]
- Next call Tuesday as usual
- 17:53:26 [Zakim]
- -Yves
- 17:53:30 [Ashok]
- Thanks to host IBM
- 17:53:30 [RRSAgent]
- I have made the request to generate http://www.w3.org/2009/03/12-ws-ra-minutes.html Yves
- 17:53:34 [li]
- goodbye and have a nice trip
- 17:53:48 [Zakim]
- -[IBM]
- 17:54:30 [Zakim]
- -Li
- 17:54:31 [Zakim]
- WS_WSRA(F2F)9:00AM has ended
- 17:54:31 [Zakim]
- Attendees were Li, [IBM], Yves
- 17:54:42 [Katy]
- Katy has left #ws-ra
- 18:35:36 [gpilz]
- gpilz has left #ws-ra
- 19:59:49 [Zakim]
- Zakim has left #ws-ra