Web Services Resource Access Working Group Teleconference -- 21 Apr 2009

<trackbot> Date: 21 April 2009

<Bob> trackbot, begin conference

<trackbot> Sorry, Bob, I don't understand 'trackbot, begin conference'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<Bob> trackbit, status

<Bob> trackbot, status

<Bob> trackbot, start telcon

<trackbot> Meeting: Web Services Resource Access Working Group Teleconference

<trackbot> Date: 21 April 2009

<DaveS> Hi Bob, I on line and will dial in in a few minutes. I'll tell you when I connect.

<Bob> scribe: Asir

<scribe> Scribe: Asir S Vedamuthu

<scribe> ScribeNick: air

<asir> ScribeNick: asir

<Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0126.html

<scribe> Meeting: WS-RA WG Conference Call

<scribe> Chair: Bob Freund

Opening

Agenda approved!

Resolution: unanimously approved the minutes at http://www.w3.org/2002/ws/ra/9/04/2009-04-14.html

New Issues

Resolution: accept all

Review of Closable Issues incorporated in 2009-03-31 snapshots

Bob: Geoff - did Doug address your comments?

Geoff: yes
... has anyone else reviewed the editors' snapshots

Bob Freund, Geoff Bullen and Doug Davis

Anyone else?

[SILENCE]

<DaveS> Davd Snelling joined the audio.

Resolution: close issues incorporated in the Mar 31st snapshots (that is, bug list in the editors' snapshot change logs)

Task Team 6413 Progress

<Geoff> We have worked on our goals.

<Geoff> We have had a con-call, but did not reach consensus.

<Geoff> Geoff has an action item to come back soon with new thoughts on how to move forwards.

Geoff: no ETA yet

Action Items

Bob motivated members to close actions

<Bob> whip whip

Issue-6739 All: Compliance section mismatch

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

Doug: use boiler plate to ensure consistency
... across specs
... retain the current wording to ensure that nothing is lost
... hoping this is editorial

Geoff: no objections to the proposed direction
... but it is only half finishing work
... some of these specs need specific wording

Bob: open to members to raise additional bugs

Doug: yes, yes

I missed the action

<scribe> ACTION: Doug to (upon completion of 6739) highlight the differences across WS-RA conformance sections [recorded in http://www.w3.org/2009/04/21-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-58 - (upon completion of 6739) highlight the differences across WS-RA conformance sections [on Doug Davis - due 2009-04-28].

Doug: apply the boilerplate, move spec specific contents to after the boiler plate text

Resolution: closed issue 6739 as proposed at http://www.w3.org/Bugs/Public/show_bug.cgi?id=6739#c0

Issue-6712 Transfer: Create is ambiguous

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

[Doug is walking through the issue]

Doug: based on last night thinking, wants a flag to indicate whether the body is a rep or something else
... not much feedback

<Yves> well, you have the URI (well EPR) and the Action, why do you need more?

[I am specifically not recording that fragment]

Yves got a good question

Geoff: anyone of the content is okay, upto the resource to figure out, rather than Doug's interpretation
... resource can support more than one type
... one simple way to resolve would be - clarify one and upto the resource to figure out which one
... willing to provide some clarification text
... is that a reasonable approach
... are there any use cases for IBM interpretation
... has anyone implemented the IBM interpretation

Yves: create is similar to HTTP PUT and URI, we have an action URI and body
... not sure I understand what Doug wants to do with additional flags

Doug: Yves is right
... passing in an EPR to copy the contents
... passing in fragement stuff
... does not matter what the instruction set is
... add the ability to provide multiple constructors
... MS interpretation, full representation | nothing
... but not allow other constructors
... Transfer spec allows that
... forcing the users to choose one or the other translating to removing features
... What about the 'Content-Type' header?
... how to interpret the data
... no hint

what about the QName of the element?

Katy: full representation or partial representation ("fragment")
... pity to restrict the scope

<Yves> why not doing a null 'create' then a 'put' from a template service?

<Yves> seems like an optimization that has impact on the complexity of handling create

DaveS: if we have a resource that has exactly one behavior then okay. the problem is want to build in pieces

<dug> yves - why force people to jump thru hoops when transfer says you can do this today

<dug> ?

DaveS: in theory, that is supported by the current transfer spec

<Katy> Dialect (or something like) enables creation of resources in other ways, for example via command if resource is very big (large policy docs)

<Yves> create from template looks more like a POST to me

Geoff: don't need a flag or dialect or something else to accomplish this

<Yves> so specific action

Geoff: many of the comments are irrelevant to the issue

<dug> yves - talk in Transfer terms please :-)

<Yves> dug :)

<Yves> like a "other action" to me

Geoff: put allows message and defers interpretation to the resource

Bob: don't have a real crisp view of what to do?

Doug: regardless of the point of view, we are not talking about adding new features .. no real differences
... can a resource support multiple types?

<dug> I'd like to point out that I'm talking about adding any features - just allowing for more than one type of create at the same time

<DaveS> DaveS's Use case summary for the minutes: A resource may need to be constructed through several steps where the resource needs to respond differently to different invocations. Dialect addresses this. The current spec is vague. A boolean (however implemented) is not rich enough.

Geoff: upto the resource to decide, not the client

<Yves> in WebDAV, COPY or MOVE are in fact doing the same thing as a PUT. Same thing here, creation of a resource is not always linked to a wst:create

[just like HTTP/REST]

<dug> but the service should be allowed to choose how many ways to expose

Geoff: add clarification text to better explain this

<DaveS> It is important that the existing implementations do not get restricted by changes we make.

<scribe> ACTION: Geoff to propose CLARIFICATION text to resolve issue 6712 [recorded in http://www.w3.org/2009/04/21-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-59 - Propose CLARIFICATION text to resolve issue 6712 [on Geoff Bullen - due 2009-04-28].

Geoff: not restriction, clarification and would like to move to consensus and not vote one versus the other

Issue 6712 - waiting for Action-59

Issue-6403 Enumeration - define policy

[Doug walks through the issue/proposal]

Doug: interesting stuff is the filter dialectg nested assertion

Geoff: no objections to using WS-Policy ... want to understand
... how we use policy assertions and its implications
... unclear been beaten around for a while
... policy as a substitute for WSDL constructs
... used for instrastructure specification
... are these specifications infrastructure specs (leaving that aside)
... there are some trade-offs
... OTOH, want to make sure that we thought through the use cases to ensure success
... how does this compose with other policy assertions defined else where
... what happens?
... say security assertions, per operation basis, per message basis, how would we solve that problem?

Doug: agrees with everything Geoff said
... opened a separate issue to discuss the impact on operations | messages

Geoff: but these issues are overlapping, what happens when I specify the enum policy assertion
... what is the relationship between the assertion and the WSDL constructs

Doug: agrees again!!!
... ... may need to tweak this, want to avoid what it means to support enumeration

Geoff: need to clearly articulate the overlapping point and then move forward
... come up some wording
... that clearly articulates what needs to be resolved

Katy: agrees with Geoff!!

<dug> no no no, Geoff agrees with Doug and Katy :-)

Katy: problem space is quite simple
... policy assertion indicates that enum MUST be used
... may be it says, may be used
... simple solution might be s/MUST/MAY/
... want to discuss implicit/explicit operations, how to associate policy expressions to implicit operations and messages

<dug> 6694: which operations are implicit

Katy: overlapping issues are 6721 and 6694

<dug> Asir agrees with Doug

Asir: elaborate on filter dialect policy assertion?

Doug: uses a QName = uri of the filter dialect, local name filter dialect
... to leverage policy intersection specified in WS-Policy

[katy, may i request you to type your comment]

Doug: started with basic functionality, made sure that the proposal can be augmented

Bob: where are we?

DaveS: move forward

Geoff: refine some language around what we are resolving and what we are not resolving
... doug took an action to describe the situation

<dug> The resolution of this issue does not preclude us from modifying this policy based on issue 6694.

Geoff: would like to work together

<dug> +1 bob

<DaveS> +1

[Bob is typing a proposal]

<Bob> resolve 6403 with the proposal in bugzilla subject to future consideration as may be required in the resolutions for issues 6721 and 6694

Geoff: not ready yet, there are a couple of issues outstanding, move forward, solving 6403 does not resolve those open issues

Katy: issue 1 - how to associate policy expressions to implicit operations | messages

<Katy> A endpoint should include a filterdialect policy assertion for each of the filter dialects that it supports.

<dug> +1

[where is this being inserted?]

<dug> end of: /wsenp:WSEnumeration/wsp:Policy/x:FilterDialect

<dug> text

Bob: are we open to resolve issue 6403 with the amendment from Katy and Bob's statement (need to resolve other issues)

Geoff: request another week to review the proposal

<DaveS> +1

[Bob is inserting Katy's amendment to 6403 proposal]

<DaveS> To the insertion into bugzz...

everyone is playing with BugZilla!

Collision .. oops oops oops

Doug messed up Bob's entry :-)

Bob baptizes 6403 with an #

Issue-6401 WS-Eventing Notifications violates WS-I BP

Gil is absent

Skip?

Bob: any questions on the proposal, has been marinating (but not ready for grill)
... let's start next week

Issue-6432 WS-Eventing Push delivery mode does not work when the

subscriber is not addressable

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

'THIS' proposal

Doug: re-baptizes 'PUSH' as 'EPR IT IS'

Bob: where are we?

Geoff: wearing a non-conflationary hat (what is that?)
... proposal uses an EPR mode, that is not specific enough
... gone backwards and forwards
... you need to parse the EPR to figure out what is going on
... parsing an EPR in an eventing code bit is not the right thing to do

<dug> I have not added any new requirements for parsing the EPR by changing the name of the Mode

Doug: changing the mode from push to epr based does not say that you need to parse EPRs

Bob: what does asynchronous mean?

Geoff: by using an EPR rather than something more specific, you are actually loosing important semantics
... no need to look into an EPR
... Geoff claims written evidence on the WG mailing list :-)

<dug> name change alone doesn't do that

<dug> if the eventing layers need to know MC is being used then it can look at the EPR just as easily as the Mode URI.

Geoff: relying on EPR means the eventing layer is left behind, does not know what delivery semantics are used

or requested by a subscriber

Bob: which parts of the proposal conflates?

Geoff: renaming is the concern

DaveS: nothing in the proposal changes the semantics of the submitted eventing
... use the default semantics
... use the push mode

Doug: what if we rename it to default mode

I heard Dave S support that

Bob: Antoine asked - what happens a subscriber behind a firewall is using that
... we need to dev a proposal for that

Geoff: push mode need to retained, create a new mode, perhaps Pull MC
... that woulld be a more viable solution

<Bob> acl li

DaveS: two choices - (a) get lost (b) change pushmode -> eprmode

Li: correctly describe the mode and then let the users figure out what to do
... could use MC even with addressible EPRs
... would like to define a new mode

[Bob is auctioning the last 60 seconds]

scribe: would like to retain the current Push mode and define a new mode

Geoff: is tied with 6692, no doubts

<DaveS> Daves Clarification for the minutes: Option A) close with no action and tell Antoine to use WS-Addressing to do it, or B) provide guidance in the specification and clarify the name of PushMode to be something less specfic.

Geoff: the current proposal conflates both push and pull

<dug> Geoff - you on IM?

<Bob> Bob adminishes folks to correct test scribed now while it is still fresh in their minds

- DRAFT -

Web Services Resource Access Working Group Teleconference

21 Apr 2009

Attendees

Contents