See also: IRC log
<Bob> we are getting organized...
<Yves> trackbot, start telcon
<trackbot> Meeting: Web Services Resource Access Working Group Teleconference
<trackbot> Date: 12 March 2009
<Yves> in another call, will dial as soon as it's finished
<Bob> ok
<Bob> scribe: Sreed
<Ashok> scribenick: Sreed
Bob: Discussion on the current
agenda for today
... Is the agenda acceptable?
<dug> add to agenda: discuss fpwd
<dug> add to agenda: discuss resolution of 6425
Bob: Agenda acceptable
... Discussion on new issues
... Any objection accepting all new issues
TRutt: Process wise it is
different
... Namespace list prefix in the exisiting schema
Bob: Implementation of resolution for 6425
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425
Wu; Li any comment
TRutt: Editing of the new resolution for this issue
Bob: Changing "are sent" to "MUST
be sent"
... came up as Li proposal
Bob: Disucss the issue 6548
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6548
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0061.html
Dug: Two cases to remove the references as discussed
Resolution: Proposal for 6548 accepted
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6577
Dug: outcome came up results to
headers
... Discussed about this issue
... It may not be necessary for the coorrelation information is
carried in wsa:relatesTo
... Consistency is good
... On request messages on response messages, there were
different in the semantics
<Bob> Dug notes that responses do carry wsrt:ResourceTransfer and a fault is just a specialized response
Bob: Updated in the additional comments section
Resolution: Issue 6577 is closed with no action
<Bob> RT Faults have their own action uri, which indicates that it is an RT fault.
<Bob> Additional header is thus not necessary.
<Bob> CWNA
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6636
Dug: Have Jeff open up a separate issue
Bob: Post the proposed
example
... Two actions
<Bob> ACTION: Doug to create an example for a representation of a resource after a create resource rel to Issue-6636 [recorded in http://www.w3.org/2009/03/12-ws-ra-minutes.html#action01]
<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].
<Bob> ACTION: Geoff to create a new issue that takes on the second part of Issue-6636 [recorded in http://www.w3.org/2009/03/12-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-47 - Create a new issue that takes on the second part of Issue-6636 [on Geoff Bullen - due 2009-03-19].
Bob: Updated in the additional comments section
<Bob> Issue to be divided
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401
Dug: Gil is working on this issue
Gil: Specific of this issue with the WS-I BP, BP says don't use notofication type operations in the port type defintion
DaveS: Why is it in-message only
TRutt: Notifications is one way only, event processing reviwed coming from the event source there is no expected response
Gi: Take port type and bind it to events source
TRutt: it is the WSDL output, what is the typical binding
Wu: Event to subscriber how do
you represent in the WSDL for concreate binding
... Outbound operations, eventing stateful
... Two choices one go through the BP
... other choice to provide an interface in-only operation for
the client
... Interface of the subscriber will have an outbound
operations specifying the interface in-only operation
DaveS: Event sync
... Simple solution define event sync which will have wrapper
around it
<Bob> gil suggests it is related to 6661
Gpliz: realted to the proposal to 6661 move apendix as it stands WS Eventing anything about the advertise
Dug: Particular issue we all are on agreement, Gil is coming out the proposal
Wu: This is technical problem there is a way to address it
Gpliz: WS Eventing specificed output operations violates the BP
DaveS: 6641 for sure
Wu: This can be technically
solved
... BP compliance solution
Bob: Updated in the Additional comments
TRutt: How do you do this in SOAP request
<Bob> ACTION: Gil with Wu and Dug to develop a proposal for the resolution of 6401 using input operations [recorded in http://www.w3.org/2009/03/12-ws-ra-minutes.html#action03]
<trackbot> Sorry, couldn't find user - Gil
<Bob> ACTION: Pilz with Wu and Dug to develop a proposal for the resolution of 6401 using input operations [recorded in http://www.w3.org/2009/03/12-ws-ra-minutes.html#action04]
<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].
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
GPilz: Apendix is incomplete
gpliz: Incorrect - output only
operations
... Woking on the proposal for this
... Eventing should provide complete solution
<dug> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Metadata
dug: Keep the apendix working group is looking at this
li: can address for the solution speciifc to usecase (outbound solution)
Katy: Remove this shouldnt effect put another metadata solution
Wu: conclusion let us take a look
Bob: Are we agreement that is it broken
DaveS: Where in the spec are you referring
Ashok: Last line editior quote this is extension in subsequent version
gpilz: WS Eventing need to address this problem - correctly
Bob: No problem with agreeing the following needs to be siginificantly corrected or removed - editiorial action
DaveS: we still have an action 6641 to work & resolve
<dug> In this version of the specification the mechanism by which an event source advertises the notifications is still undefined but is being investigated.
DaveS: it is the metadate exchange includes the policy we have plenty of work to do, this get the BP problem clear
Wu: Propose clear idea solution for 6401
gpliz: Oracle don't object to it
<Bob> Wu wishes to delay consideration until 6401 is resolved
gpliz: Apendix A is kind of wrong
<dug> In this version of the specification the mechanism by which an event source advertises the notifications is still undefined but is being investigated.
dug: we still need to look into this problem
<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
DaveS: we can wait
Ashok: work in progress
Bob: adding dependency for 6401
<Bob> defer until consideraton of future proposal to 6401
<Bob> replace the mumble above with Bob added a dependency in 6661 to 6401
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432
<Bob> sounds like
dug: Push means push/pull EPR Eventing system no changes, in Infrastrcture layer
DaveS: Client is in control in this situation
Bob: respond to reviwer composing to make connection with specific example
Wu: I second to Bob
comments
... works prefer to put an Appendix as how it supports - events
can be extended to support
... Major change in their implementations
Ashok: Second mode - polling last 10 messages to be sent what would happen
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)
... Event queue does the messages in FIFO
dug: First pull may not be notofication
gpliz: Entire system a "kind" of pull mechanisim event source of view kidn an asynchronus reponse message
<Wu> Wu: or put in the primer to illustrate how WS-E can support pull mode
gpliz: support make connection, how fast the notification generated, how many subscribers so need to support entire messages in the queue
Bob: it is not a poll mode it really handles the addressable client
<Bob> ack dug, gp
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
... Message can be generated in this mode
... it is an implementation choice
... changes to spec rename to push to something else
... EPR based model
<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
<gpilz> +1
DaveS: Pull point technology be a
subsequent spec on top of this
... Subscription point needs to advertise make connection has
its policy
... may be shows up in the spec
gpliz: we need issue address how the policy does this
Bob: Make connection is a solution
gpliz: I agree completely with TRutt said
<Bob> ack
gpliz: dug raised an good point - trying to get the notofications behind the firewall we recommend about the make-connection in the spec
DaveS: looking at spec
itself
... Pull-model we do have URI subscription on this
... Client is concerned need to setup make connection, don't
recognize the mode
gpliz: support make connection send me subscription back
dug: require expliclty pub/sub engine
Bob: Recommendation in spec is necessary?
<dug> change ref from pull mode to delivery of events to non-addressable endpoints
<Bob> s/typically referred to as
<Bob> Pull mode/delivery of events to non-addressable endpoints
<Ashok> Bob: Proposal -- Replace 'push' with EPR-based'
<Sreedh> Bob: Section 3.3
<Sreedh> dug: making push mode, EPR mode will be default
<Sreedh> Wu: Keep push mode
<Sreedh> Wu: Event to non-addressable
<Sreedh> dug: even though we use Push it will would specifiy addressable or non-addressable
<Sreedh> dug: recommended way to do that
<Sreedh> gpliz: problem with push mode it is more visible
<Sreedh> gpliz: do it with make connection on event sync side
<Sreedh> gpliz: lot of different ways in EPR
<Sreedh> gpliz: need to keep push
<Ashok> How about "shove" :-)
<gpilz> need to mention that "push includes pushing to non-addressable EPRs via WS-MakeConnection"
<Bob> +1 to shove mode
<dug> LOL +1
<Sreedh> Katy: Could we used distribute mode?
<li> push is event source initiated and implies timely delivery, these are not provided makeconnection
TRutt: Application invokation model from the sensibility I dont mind changing the name
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
<Ashok> scribenick: Sreedh
<Bob> scribenick: Sreed
gpilz: Event sycn uses make-connection two different views is an issue, should they both one mode or two mode
WS Eventing mention the use of make connection that should recommend that it should use it
gpliz: There is timing if I am adderssable sufficient pop-up listener now or later ie time/deliver mode
<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.
<dug> push could push events to a mailbox so timely is a bit ambiguous
gpliz: most efficient way
Wu: we should keep Push-mode
atleast it is understood if there is new addition to this
shouldn't create confusion
... Need to have solution
<Bob> Wu: add one sentence somewhere that mentions makeconnection
dug: need to make changes, also
try to understand definition of push-mode
... we are not going further
Wu: Push-mode is applied to addressable EPR
Dug: why
Wu: notion of addressable EPR how it works
dug: we don't explain how to do
push-mode
... how is this applicable to WS Addressing
Bob: Dug & Wu need to work together on this
Wu: there are many solutions are addressing these issues
Katy: why can't we specify this is recommended
<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
<Bob> ACTION: Doug and Wu to work on a new proposal to resolve 6432 [recorded in http://www.w3.org/2009/03/12-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-49 - And Wu to work on a new proposal to resolve 6432 [on Doug Davis - due 2009-03-19].
Bob: Accepted 6691 & 6692 as new issues
<Bob> scribe: Ashok
<scribe> scribenick: Ashok
Dug: Create new section (don't
need new namespace) with top-level-element which contains all
the options you support
... pretty much focussing on filter dialect
... Use namespace of filter dialect to specify dialect
... can intersect policy using simple QName matching
... Same template can be used for other specs
Katy: Will enum operations ever appear on WSDL
Dug: If implicit and required they do not appear on policy, if optional must appear on policy
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
<Wu> Wu: Discussion issue 6403 about policy
Wu: Make it light!
<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.
<Katy> ... This could be done by nesting the policy for the implicit operations within the emumeration policy
<Katy> ... I will raise an issue to addres across specs
<scribe> ACTION: Katy to create issue for policy issue for implicit operations [recorded in http://www.w3.org/2009/03/12-ws-ra-minutes.html#action06]
<trackbot> Created ACTION-50 - Create issue for policy issue for implicit operations [on Katy Warr - due 2009-03-19].
Wu: Need more time to consider
Dug: I'm happy to accept changes on this later
Bob: I have heard nothing about
this issue for some time
... I will give you week ... not on Tuesday's call but the
follwing call
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6632
Dug: This is a Transfer issue ... I would like to reassign to Transfer
<Yves> +1
Bob: Any objection to reassigning this?
RESOLUTION: Reassign to WS-T
Bob: General case of server being unable to provide response ... perhaps be just a general "cannot comply" fault
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6633
Dug: This is a generic Transfer issue ... not only to fragments
DaveS: This nightmare
s/bib//
DaveS: Bigger problem in RT but
applies to T as well
... we need to answer in both places
Dug: If we move to T, RT would be able to leverage same solution
<Bob> entered into the isue comment:
<Bob> This seems to apply to both RT and T, may occur more frequently in RT, but both need resolution.
<Bob> It MAY be possible to find a repair in T that could be leveraged by RT.
<Bob> The issue related to xpath needs to be investigated and may need a new related issue resolution.
RESOLUTION: Reassign to WS-T
scribe: can be caused when namespace not mentioned inside the body
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6551
Dug: Can run out of time updating whole resource as well ... RT can piggyback on that fault
Katy: Transfer this to T and pull over RT fault
DaveS: Can fail with partial update
Bob: ACID criteria for updates?
Dug: Goeff has opoened another,
related issue
... lets transfer this and then discuss the other issue
<Bob> entered into comment:
<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.
<Bob> r-assign to T then re-visit
RESOLUTION: Reassign to WS-T
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6422
Dug: you can have same problem in
WS-T world
... applies to Transfer
DaveS: Or it does not apply if there is idempotency
<Yves> boxcarring to T makes no sense
<Yves> and what happens if there is a fault in the middle of processing all the changes to the same doc? rollback?
<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
RESOLUTION: Leave in RT but make sure RT follows T in terms of idempotency
<Bob> comment entered:
<Bob> Highlights that RT should follow idempotency properties of T, then might depend on specification of restrictions as to frags permitted
Bob: Shall we adjourn?
Adjourned
Next call Tuesday as usual
Thanks to host IBM
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/must/MUST/ Succeeded: s/6548/6548 accepted/ Succeeded: s/information/information is carried in wsa:relatesTo/ Succeeded: s/6641/6401/ Succeeded: s/6641/6601/ Succeeded: s/6601/6401/ Succeeded: s/necessary/necessary?/ WARNING: Bad s/// command: s/typically referred to as Succeeded: s/2/2 as new issues/ Succeeded: s/supprt/support/ FAILED: s/bib// Succeeded: s/big// Found Scribe: Sreed Found ScribeNick: Sreed Found ScribeNick: Sreedh WARNING: No scribe lines found matching ScribeNick pattern: <Sreedh> ... Found ScribeNick: Sreed Found Scribe: Ashok Inferring ScribeNick: Ashok Found ScribeNick: Ashok Scribes: Sreed, Ashok ScribeNicks: Sreed, Sreedh, Ashok WARNING: No "Present: ... " found! Possibly Present: Ashok Bob DaveS GPilz Gi Gil IBM Katy Sreed Sreedh TRutt Vikas Wu Yves ammend dug gpliz jeffm joined li scribenick trackbot ws-ra You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0064.html Found Date: 12 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/12-ws-ra-minutes.html People with action items: doug dug geoff gil katy pilz with wu[End of scribe.perl diagnostic output]