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
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]
13:01:36 [li]
li has joined #ws-ra
13:01:50 [Bob]
13:02:24 [Zakim]
WS_WSRA(F2F)9:00AM has now started
13:02:31 [Zakim]
13:04:35 [Zakim]
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]
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]
13:24:23 [Bob]
Topic: Issue-6548
13:24:56 [Sreed]
Bob: Disucss the issue 6548
13:25:06 [Sreed]
13:25:08 [Bob]
proposal at
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]
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]
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]
13:38:21 [Sreed]
Topic: 6636
13:38:27 [Sreed]
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]
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]
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]
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]
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]
13:56:35 [TRutt]
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]
13:59:14 [li]
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]
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]
14:06:55 [dug]
14:07:22 [Katy]
14:07:54 [Wu]
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]
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]
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]
14:16:58 [dug]
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]
14:22:58 [Bob]
defer until consideraton of future proposal to 6401
14:23:08 [dug]
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]
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]
14:28:03 [Wu]
14:28:06 [Bob]
ack bob
14:28:11 [Ashok]
14:28:55 [dug]
14:29:07 [gpilz]
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]
14:30:06 [Bob]
ack wu
14:30:22 [TRutt]
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]
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]
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]
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]
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]
14:46:38 [Bob]
14:46:41 [Bob]
14:46:44 [Bob]
14:46:45 [Wu]
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]
14:47:32 [Bob]
ack wu
14:47:40 [dug]
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]
14:53:13 [Bob]
ack dug
15:08:11 [Sreed]
Bob: Recommendation in spec is necessary
15:10:38 [Bob]
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]
15:18:50 [li]
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]
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]
15:24:02 [DaveS]
15:24:18 [Bob]
ack katy
15:24:39 [gpilz]
15:24:43 [Sreedh]
Katy: Could we used distribute mode?
15:24:44 [Wu]
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]
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]
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]
15:36:48 [Sreed]
Bob: Dug & Wu need to work together on this
15:41:46 [gpilz]
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]
16:02:01 [Zakim]
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]
16:51:19 [Ashok]
scribenick: Ashok
16:51:37 [Bob]
Topic: 6403
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]
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]
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]
17:05:51 [Ashok]
Bob: I have heard nothing about this issue for some time
17:06:28 [Bob]
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]
17:11:45 [Ashok]
Dug: This is a Transfer issue ... I would like to reassign to Transfer
17:12:39 [Yves]
17:14:09 [Zakim]
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]
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]
17:21:11 [Ashok]
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]
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]
17:38:07 [dug]
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]
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]
17:53:19 [Ashok]
Next call Tuesday as usual
17:53:26 [Zakim]
17:53:30 [Ashok]
Thanks to host IBM
17:53:30 [RRSAgent]
I have made the request to generate Yves
17:53:34 [li]
goodbye and have a nice trip
17:53:48 [Zakim]
17:54:30 [Zakim]
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