<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 of new issues
... Any objection accepting all new issues?
... No objections, all new issues accepted and assigned to their proposer.

Doug first public working draft

TRutt: Process wise it is different
... Namespace list prefix in the exisiting schema

Implementation of resolution to Issue-6425

Bob: Discussing the implementation of resolution for 6425

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425

Bob: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
... any objections?, none heard

Resolution: Change in resolution of Issue 6425 "are sent" to "MUST be sent"

Issue-6548

Bob: Discuss 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 without objection

Issue-6577

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 form of response

Bob: Updated in the additional comments section

<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

Resolution: Issue 6577 is closed with no action

Issue-6636

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6636

Dug: Have Geoff open up a separate issue on the second part

Bob: Please 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

Issue-6401

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: related 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 specified 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: 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].

Issue-6661

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661

GPilz: Apendix is incomplete

gpliz: Incorrect - output only operations
... Working 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 appendix, the 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 first then look at it again

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 in 6661 to 6401

<Bob> defer until consideraton of future proposal to 6401

Issue-6432

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432

dug: Push means push/pull EPR Eventing system no changes, in Infrastrcture layer

DaveS: Client is in control in this situation

Bob: respond to reviewer proposing composition with 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

Dug: make connections is not mandate it is more logical to do it. Polling messages from 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

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: Is a recommendation in the spec 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

Bob:Proposal -- Replace 'push' with EPR-based'

Bob:Section 3.3

Dug:making push mode, EPR mode will be default

Wu:Keep push mode

Wu:Event to non-addressable

Dug:even though we use Push it will would specifiy addressable or non-addressable

Dug:recommended way to do that

GPilz gpliz: problem with push mode it is more visible
... do it with make connection on event sync side
...lot of different ways in EPR
... 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

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

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 w/o

<Bob> scribe: Ashok

<scribe> scribenick: Ashok

Issue-6403 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403

Bob:Proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0007.html

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 next Tuesday's call but the follwing call

Issue-6632

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

Issue-6633

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6633

Dug: This is a generic Transfer issue ... not only to fragments

DaveS: This a nightmare

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

Issue-6551

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 opened 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

Issue-6422

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