Web Services Addressing WG Teleconference

11 Sep 2006

See also: IRC log


Francisco Curbera (IBM Corporation)
Paul Downey (BT)
Robert Freund (Hitachi, Ltd.)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
David Illsley (IBM Corporation)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Mark Little (JBoss Inc.)
Yves Lafon (W3C)
Jonathan Marsh (Microsoft Corporation)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Katy Warr (IBM Corporation)
Prasad Yendluri (webMethods, Inc.)
Abbie Barbir (Nortel Networks)
Andreas Bjarlestam (ERICSSON)
Dave Chappell (Sonic Software)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Philippe Le Hegaret (W3C)
Amelia Lewis (TIBCO Software, Inc.)
Bozhong Lin (IONA Technologies, Inc.)
Jeganathan Markandu (Nortel Networks)
Jeff Mischkinsky (Oracle Corporation)
Nilo Mitra (ERICSSON)
Eisaku Nishiyama (Hitachi, Ltd.)
David Orchard (BEA Systems, Inc.)
Alain Regnier (Ricoh Company Ltd.)
Davanum Srinivas (WSO2)
Pete Wenzel (Sun Microsystems, Inc.)
Bob Freund
Tony Rogers


Minutes of the last meeting

No objections - minutes of the last meeting accepted

Action Items

<scribe> Chair: we need more participation in the testing activities

Tony to implement the changes in response to CR31 - pending

Coordination with WS-Policy Group

MarcH: good if the Policy Attachment spec described the merging / overriding of policy attached to an EPR with policy embedded in an EPR
... there is some confusion on whether it overrides, but not clear

<scribe> Chair: are the members of the group satisfied that it is up to the Policy WG to define what happens?

Paco: yes

MarcH: the spec isn't clear, but it's up to them

<pauld> it may or may not be their issue, but for sure it's not our issue :-)

<scribe> Chair: I will communicate to their WG that the ball is in their court - their problem


<scribe> Chair: potential effects on WS-Reliable Messaging and XMLP of CR33

<scribe> Chair: scheduling time on Wednesday (WS-CG) for dealing with this issue

<scribe> Chair: may need a joint meeting of WS-Addr, WS-Reliable Messaging, and other interested parties to address this issue

JonM: suggested an alternative proposal using RefParms

Dug: TAG frowns on that approach

<scribe> Chair: This is not related to the identity issue, which is where the TAG was concerned

<scribe> Chair: It indicates which type of response the server will generate?

Dug: no, it indicates the identity of the endpoint
... it's not identifying the message, but rather the endpoint

JonM: not convinced that it's identifying the endpoint - there's only one backchannel, so how we disambiguate them

<Dug> +1 Gil

Gil: the problem with trying to use RefPs is (DaveO's opinion): one is supposed to echo the RefPs to the client - the server is NOT supposed to "crack open" the RefPs
... this is crossing the line between RefParams and RefProperties (and we have removed RefProps from WS-Addr)

DaveH: the way we defined Anonymous in WS-Addr carefully avoided any discussion of channels and back-channels. We said that it's valid only in a particular context. When Anon is used for a response endpoint, then one puts the message in the Response part of a Request-Response MEP.
... carefully avoiding discussion of backchannels, it's a behavioural cue
... In the WS-RX context, we are still talking about using the Response portions of future messages (and their MEPs). Only context we have in this is the sequence id.

Paco: there doesn't seem to be a lot of convergence to this discussion. Chair's desire to resolve this in a joint meeting is a good idea

<Dug> +q

<scribe> Chair: in terms of alternative proposals: we have Jonathan's new one, and the one from last week

<pauld> and the Status Quo

Dug: if we could loosen up the wording relating to the anonymous URI, we could resolve it that way

<anish> i also think that it is identifying the endpoint not the sequence

<anish> tony, the wsrm uri is not a single uri but a template

MarcH: there seem to be two ideas as to what is being identified. Would like to understand why they think these are different

Dug: there needs to be some unique field in the message to identify which client (potentially among many clients) is "on-the-line" for receiving responses

JonM: the "small change" requested makes the coding for the wsaw:Anon assertion radically different - has a dramatic impact on the WS-Addressing implementation

<Dug> I have implemented it and coding it up isn't messy :-)

JonM: it requires making the WS-A implementation aware of WS-RX

Gil: there's an inherent contradiction. The RM protocol is inherently one-way. It allows the client to contact the server at arbitrary times to solicit responses.

<pauld> but presumably Dug, your implementation wasn't a WS-Addressing which didn't know or care about WS-RX, then had WS-RX layered upon it?

Gil: The server doesn't have that option if the client cannot "listen" for responses. So how does the server re-send responses if it thinks the client hasn't received them?
... Does that clarify the rationale for this issue?

<gpilz> oops

Bob: can visualise multiple solutions to this problem. Thinking in terms of layered implementations, perhaps there's a layer under RM that handles the virtual proxying of these queued messages.

DaveH: if I understood Gil correctly, the idea is that the "magic cookie" tells the RM server who is contacting it and therefore is ready to receive a response. Leaning towards JonM's position

MarcH: Sounds like RM is overloading ReplyTo to mean where the reply should go, PLUS which reply to get (which queue of responses to get a response from)

Dug: No, that's not how it works.

<Dug> ok bob - I remember now :-) sorry

Anish: the RM group considered four options for tackling this problem
... decided to go with the template approach for good reasons

<Dug> dhull - wouldn't that be transport specific?

<dhull> How so? I send MakeConnection(anon, 12345). E.g., one child is anon, one is 12345. You could also use this with a non-anon URI. It's basically multiplexing behavior. (I'm not sure I yet grok why ref params don't work, but I'll take that on faith)

Bob: the queuing layer at the bottom of RM is the application receiving the content of the RefParam, and is therefore NOT a violation of the opaqueness criterion

<dhull> Hmm ... could I get one message for the connection on anon and one on non-anon? E.g., I happen to know who you are. I try pushing a message to you. Sometimes it works. Sometimes it doesn't, but you're also sending me messages. So if I see one of those I piggyback on it.

Dug: the impact on the code is minimal, because it just means that the code which interprets the URI changes to add a case for handling these kinds of URI

<Yves> Yves notes also than a 202 to return something other than information about the _processing_ of the request is invalid. Also sequence of req/resp should be taken cautiously, as a proxy might be in between and ruin assumptions

<Jonathan> soory, phone seems fritzy

Anish: people who are pushing back on the proposal, are they suggesting that RM define a RefParam at the MakeConnection level?

<Jonathan> A WSDL extension can say, "extend wsaw:Anonymous to include pseudo-anonymous."

<Jonathan> one way only

<Jonathan> one way only

<Jonathan> yes

<Jonathan> 2will redial

Dug: how do we define a new marker in RM to provide the pseudo-anon capability?
... need ability to have both markers (WS-A anon and RM anon) in a WSDL, to support both RM-aware and non-aware apps.

<Jonathan> please continue!

Anish: don't like the idea of having one marker override another - distasteful solution

Dug: if we can't extend the existing marker, can we have an extensibility point here?

Anish: it's more than that - it's a case of overriding the semantics of the existing marker

Katy: when we were discussing this, we decided to keep it simple. Not inclined to change it now

<scribe> Chair: are we ready for a straw poll on this?

bob:: choices: close with no action, accept Dug's proposal

<Dug> proposal: just tweak the wording but keep same name/semantics

<Dug> to talk about async

Anish: third option: find a compromise that makes everyone equally unhappy

Dug: fourth option: change wording to describing in terms of asynchonicity

<Katy> Tony: Yes - point was wsaw:Anonymous complicated enough for little extra benefit

<Katy> don't need extensibility points too

Dug: code already looks at the URI to send messages to, so the code changes are minimal

Tony: Not true - that code is not expected to change up to a different layer of code to select a different message to send

TomR: want the poll to allow incorporate the option of small changes to clarify matters

<Dug> Tony - the logic to get a msg may be hard or easy - I agree,but its not a big hit to the "current" WSA code - no comment on how big the new code is.

<Katy> <wsap:AddressableResponsesOnly/> and <wsap:NonAddressableResponsesOnly/>

Katy: if we are considering changing the wsaw:AnonymousRequired, perhaps we should allow the use of two flags: <wsap:AddressableResponsesOnly/> and <wsap:NonAddressableResponsesOnly/>

<Zakim> Jonathan, you wanted to dispell incomposability argument

Anish: was suggesting giving it more time to find a compromise

<scribe> Chair: do we think we should try to solve this; do we think this is not our purview; do we need to involve everyone else (XMLP / TAG / et al)?

<scribe> Chair: not seeing much progress today

<pauld> chad, options for issue-33

<pauld> chad, option 3: summit

<pauld> chad, option 2: status quo

<pauld> option 1: head-banging

<pauld> chad, question: options for ISSUE-33

vote: 3, 2, 1

<pauld> chad, option 1: head bangign

<dhull> vote: 2, 1, 3

vote: 3, 2, 1

<TRutt_> vote: 1

<anish> vote: 1, 3

<Jonathan> vote: 2, 3

<Katy> vote: 3

<Yves> vote: 3, 2, 1

<marc> vote 2, 3

<pauld> vote: 2

<marc> vote: 2, 3

<pauld> chad, option 1: head banging

<gpilz> vote: 1, 3

<prasad> vote: 2, 3

<pauld> chad, count

<chad> Question: options for ISSUE-33

<chad> Option 1: head banging (3)

<chad> Option 2: status quo (5)

<chad> Option 3: summit (3)

<chad> 11 voters: anish (1,3),dhull (2,1,3),gpilz (1,3),Jonathan (2,3),Katy (3),marc (2,3),pauld (2),prasad (2,3),TonyR (3,2,1),TRutt_ (1),Yves (3,2,1)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Tie when choosing candidate to eliminate.

<chad> Tie at round 1 between 1, 3.

<chad> Tie broken randomly.

<chad> Eliminating candidate 1.

<chad> Round 3: Tie when choosing candidate to eliminate.

<chad> Tie at round 2 between 2, 3.

<chad> Candidate 3 has the fewest votes at round 1.

<chad> Eliminating candidate 3.

<chad> Candidate 2 is elected.

<gpilz> me "strange little bots with obscure syntax are no basis for a system of government"

<chad> Winner is option 2 - status quo

<Dug> +1 to the 2nd part :-)

<scribe> Chair: not a clear position - close to balance between close with no action and continued head-banging

Tony: I'd like to see more detailed descriptions of approaches on the e-mail list

<scribe> Chair: will take this issue to WS-RM to assess their position

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/10/03 14:41:04 $