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