Web Services Addressing Working Group Teleconference

5 Dec 2005


See also: IRC log


Andreas Bjärlestam (ERICSSON)
Tony Cicala (HP; substituting for Yin-Leng Husband)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Jacques Durand (Fujitsu Limited)
Robert Freund (Hitachi, Ltd.)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
David Illsley (IBM Corporation)
Anish Karmarkar (Oracle Corporation)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Mike Vernal (Microsoft Corporation)
Steve Vinoski (IONA Technologies, Inc.)
Katy Warr (IBM Corporation)
Pete Wenzel (Sun Microsystems, Inc.)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Abbie Barbir (Nortel Networks)
Dave Chappell (Sonic Software)
Eran Chinthaka (WSO2)
Michael Eder (Nokia)
Marc Goodner (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Paul Knight (Nortel Networks)
Philippe Le Hégaret (W3C)
Amelia Lewis (TIBCO Software, Inc.)
Bozhong Lin (IONA Technologies, Inc.)
Jeff Mischkinsky (Oracle Corporation)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Rich Salz (DataPower Technology, Inc.)
Davanum Srinivas (WSO2)
Jiri Tejkl (Systinet Inc.)
Mark Nottingham
Marc Hadley


<marc> scribe: marc

2. Agenda review, AOB

no ob

3. Call for corrections to the minutes

2005-11-21: <http://www.w3.org/2002/ws/addr/5/11/21-ws-addr-minutes.html> approved

2005-11-28: <http://www.w3.org/2002/ws/addr/5/11/28-ws-addr-minutes.html> corrections pending

4. Review action items <http://www.w3.org/2002/ws/addr/admin#actionitems>

Umit - done

Jonathan - open

5. Co-ordination

* TAG request for help


Mark reviews note from TAG

Mark: does WG feel the need for formal response ?

<pauld> wonders what we can do, or care about how other people use our specs

dhull: wonders if we need something to explain migration from submission

WG is OK with informal response to TAG

other 5. Proposed and New Issues

Jonathan reviews the issue

<GlenD> Nothing prevents anyone from using <wsa:UsingAddressing> as a policy assertion element under <wsp:Policy>, does it?

<uyalcina> Exactly

<uyalcina> this is what I wrote on my email

<GlenD> +1 on extensibility

Mark: such a policy assertion would need to be compatible with WS-Policy ?

Jonathan: yes

<uyalcina> +1

<GlenD> dammit!

Mark: have discussed with several people, feedback indicates that charter changes might be required

Jonathan: charter requires us to define a mechanism for indicating use - policy is one way of doing that. can be done without normative reference to WS-Policy.

<mnot> scribe: mnot

march: know of people developing policy constraints; would like to use that instead of a specific policy language.
... Would like to speak against domain-specific policy langauge; want to use something domain-independant one (which is usable with WS-Policy).
... Urge WG to look at WS-PolicyConstraints.

<scribe> scribe: marc

<GlenD> +1

<GlenD> <wsp:Policy>+1</wsp:Policy>

<pauld> AIUI Anne's OASIS dipal working group is based upon XACML: http://research.sun.com/projects/xacml/

<bob> and it is looking very interesting

umit: can use existing extension elements in WS-Policy, good enough, lets move on

<dhull> +1

Paco: in favor of defining policy assertions
... existing elements can be r-used in policy language when that gets standardized

anish: can't see any need to say anything about policy right now

jonathan: need a policy assertion, I can either talk to paco and IBM and MS can define it or we can do it in the WG. Former is not that unattractive as bilaterally we can define waht we want and twiddle it whenever we want. Doing it in the WG is a low cost way to get this on a standards track.

umit: don't want to see another policy assertion document elsewhere, lets do this in the WG
... just need an indication that the elements we define can be used in policy and leave it at that

<Zakim> hugo, you wanted to answer the question: should we open the issue?

hugo: don't think we need to open an issue for this
... from charter pov, we have defined WSDL extensions

anish: thinks jonathans suggestion re MS and IBM defining this is the best way to go

<Zakim> dhull, you wanted to ask a quick question

<uyalcina> why are we abstracting concrete QNames, Anish?

dhull: nothing prevents our elements being re-used - right ?

jonathan: nothing structural, but thinks such use would be viewed as abuse

umit: (to hugo) thinks if we don't open this issue then we are asking for it to happen elsewhere

glen: doesn't think use of our elements elsewhere would be viewed as abuse

mark: if we open this to use with policy then we would need to track usage quite closely

<anish> +1 to marc

<hugo> +1 to Marc

<bob> +1 to Marc too

marc: either do the job and define use in each framework or don't do it, making some vague statement will do nobody any favours

mark: what is your preference ?

<TonyR> +1

<bob> note that you are now requiring a very high bar...

marc: would like a standardized policy framework to do the work against, in absence of such don't see what we can do

tony: policy not in a state where we can reliably define something for use in it

pauld: would like to see some concrete proposals

Mark: could accept this as an issue and explore solutions that are not specific to any policy framework

hugo: there was quite a bit of opposition, can we poll to see level of interest

mark: if we open the issue then ill be tightly scoped to a couple of generic sentences saying elements can be used elsewhere

jonathan: that's acceptable

paco seconds the issue

<mnot> ACTION: Jonathan to make concrete, non-referencing proposal for new issue WRT policy. [recorded in http://www.w3.org/2005/12/05-ws-addr-minutes.html#action01]


umit presents her proposal

mark: lots of discussion on email

umit: lets agree to incorporate the proposal and then work on the comments as separate issues

jonathan: q re prohibited value, is that really a common requirement ?

umit: voted at F2F

<pauld> ack, pauld

dhull: seems that WS-AT requires this

jonathan: any other cases ?

umit: application level requirements

anish: nice indication at binding that responses will not come back on back channel, good to know beforehand rather than find out at runtime

<dorchard> +1 to app level requirements

<uyalcina> what I am saying is that application level requirements may require async bindings. In this case, this marker will be useful even it is at the binding level

<uyalcina> of course, you can build async applications on top of sync protocols too, but if we had a long running request response at the app level, it will REQUIRE an async binding.

gil: thinks there are cases where this is important and that it would be odd if that was not possible in WSDL

<Zakim> dorchard, you wanted to add a bit to gil's point about ws-rx.

dorchard cites WS-RX case where WS-Addr capability can be used to indicate support for anon/non-anon RX replies

paco: doesn't understand RX use case well enough but looks like partitioning of functionality isn't the most appropriate way to do it

<Zakim> uyalcina, you wanted to ask a q to Anish

umit: same use case as anish, long running request response
... the markup enables applications, think we should keep it

anish: WSDL 1.1 abstract isn't that abstract so use of this markup isn't that counter

umit: make a high level decision on whether to incorporate this or not

marc: don't want to incorporate a lot of text that is open to change, don't think the proposal is ready yet


working through point raised in above referenced email

(i) agree this is an issue

(ii) similar to wsaw:Action seems appropriate

<dorchard> + to MarcH

<dorchard> +1 to MarcH

<gpilz> +1 to not cramming everything into the WSDL binding document

(iii) agreed

(iv) and (v) generated a lot of discussion wrt to whether new bindings are being defined or required


jonathan: in wsdl 2.0 we always include an explicit way of saying the same thing as the default

marc: ok with leaving it in


umit: didn't think too deeply on this one, wanted to keep BP semantic but also thought there were cases where a reply envelope would be required

jonathan: related to the RM question of sending ack back ?

umit: yes

<gpilz> this "open door" is just "request with optional response" by another name

<gpilz> not that that is a bad thing

<dhull> not convinced

<dhull> (either way)

anish: so 202 SHOULD NOT include a SOAP envelope and we can revisit

umit: yes

<gpilz> WS-RX has problems if there is no SOAP envelope

<dhull> How about SHOULD follow BP, as opposed to SHOULD NOT not follow it?

<dorchard> Hard to imagine w3c spec normatively referring to ws-i spec. Pretty much flies in the face of "we just do profiles"...

<pauld> where is the WS-I 'one-way' binding, is there a URI?

look for 202 in BP

Summary of Action Items

[NEW] ACTION: Jonathan to make concrete, non-referencing proposal for new issue WRT policy. [recorded in http://www.w3.org/2005/12/05-ws-addr-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/12/08 22:55:18 $