See also: IRC log
<trackbot> Date: 21 April 2009
<scribe> Scribe: Asir S Vedamuthu
<scribe> ScribeNick: asir
<scribe> Meeting: WS-RA WG Conference Call
<scribe> Chair: Bob Freund
Resolution: unanimously approved the minutes at http://www.w3.org/2002/ws/ra/9/04/2009-04-14.html
Resolution: accept all
Bob: Geoff - did Doug address your comments?
... has anyone else reviewed the editors' snapshots
Bob Freund, Geoff Bullen and Doug Davis
<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)
<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
Bob motivated members to close actions
<Bob> whip whip
Doug: use boiler plate to ensure
... across specs
... retain the current wording to ensure that nothing is lost
... hoping this is editorial
Geoff: no objections to the proposed
... 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
[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
<Yves> well, you have the URI (well EPR) and the Action, why do you need more?
AsirYves got a good question
Geoff: anyone of the content is okay,
upto the resource to figure out, rather than Doug's
... 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: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
... 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
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
... can a resource support multiple types?
<dug> I'd like to point out that I'm not 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
[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
... 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
... 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
... 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
[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.
[where is this being inserted?]
<dug> end of: /wsenp:WSEnumeration/wsp:Policy/x:FilterDialect
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
[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 #
Gil is absent
Bob: any questions on the proposal,
has been marinating (but not ready for grill)
... let's start next week
subscriber is not addressable
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
... 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 text scribed now while it is still fresh in their minds