Web Services Addressing WG Teleconference

16 May 2005


See also: IRC log


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


review agenda

chair: any additional items? None.

go over minutes

chair: can we approve? Minutes approved


chair: anish issue item 4 for Berlin

anish: can I please have a deadline?

chair: next Monday

AI for Glen. Did it, but it hasn't turned up yet.

Gudge - not done AIs yet. Will be done by end of call.

Jonathan lc6 done AI

M Hadley done AI.

last call issues

chair: pulled out easy ones to start with.


Duplicate of earlier IRI issues; Jonathan to write back to Jacek and explain.


RESOLUTION: editorial - accept


RESOLUTION: editorial - accept

<prasad> +1

RESOLUTION: jonathan accepted and was on call

<Marsh> I accept the resolution of issue LC74 as a satisfactory resolution of my comment :-)


chair: is this just the semantics of wsa headers or any other headers?

paco:all headers

anish: why would we want to prevent wsa:action in a header? seems like you may want to do this.

paco: seems to require a SHOULD NOT rather than MUST NOT

general discussion: is there a really good reason for putting wsa in refparams? not sure. but if we disallow this we'd require the parsing of all refparams to check.

daveo: leave unspecified.

chair: someone write up proposal for discussion?

<mnot> ACTION: Glen to write proposal for lc77 [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action04]


RESOLUTION: editorial


RESOLUTION: editorial


<Marsh> We should change: "The reply to a WS-Addressing compliant request message MUST be compliant to WS-Addressing and is constructed according to the following rules:"

chair: defer


<Marsh> To "The reply to a WS-Addressing request message is constructed according to the following rules:"

RESOLUTION: accept and editorial


RESOLUTION: accept and editorial


RESOLUTION: accept and editorial


RESOLUTION: accept and editorial to update references


anish: has to be serializable with xml 1.0, but you don't have to use xml 1.0 - could use 1.1?

chair: agreed. So issue is to state that as long as 1.0 can serialize it then it's fine?

anish: +1

RESOLUTION: not relevant issue. close lc96 no action.


RESOLUTION: accept and editorial


RESOLUTION: accept and editorial


RESOLUTION: close. duplicate of lc13


RESOLUTION: accept and editorial


RESOLUTION: accept and editorial

<scribe> ACTION: Jonathan to write back to reviewer on lc106 and look into notational conventions

lc 107

paco: reply not necessarily tied to response in wsdl

<plh> Web Services Glossary -> http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/

paco: text in section 3 for this issue
... dont' want limiting definition of request-reply

marc: current text is too subtle

paco: happy to take AI to clarify

<mnot> ACTION: Paco to continue discussion of lc107 on the list. [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action07]

<scribe> continue discussion on list. leave open


jonathan: interesting to add regardless. Sizeof refparams - too large could cause denial of service attack.
... may want to limit size.
... scarce resources - how many sockets service has open; might be possible to send enough eprs to exhaust.

anish: why is this special?
... true for any header (xml related, not ws-addr specific).

chair: not exposing self, but exposing someone else?

jonathan: nope
... really is ws-addr specific. complex headers take time to process (potentially blocking).

caveat emptor

jonathan: developer feedback. better in the spec than out?

##any too?

jonathan: will go back to security guys and check

tony: small messages may expand while being processed
... "pass by reference"

chair: asks jonathan to go back and check

anish: the idea of causing someone else to be the victim is intertesting

<mnot> ACTION: Jonathan to come back with more information on lc37 [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action09]

lc 38

jonathan: non-neg integer for retry value on fault. prefer something that does not have arbitrary number of digits. may become implementation dependant.
... unsigned int or long

chair: look at lc73 too

paco: likes jonathan's proposal, which covers all reasonable scenarios.


<bob> +1

+1 for unsigned long

<dhull> unsigned long, but would take unsigned int

XP can be slow sometimes ;-)

<bob> anything longer than a fortnight is ok

<dhull> +1

RESOLUTION: accept lc 38 and use unsigned long.


<bob> I favor the never expected to be successful

marc: lc73 - if value omitted retry is never expected to be successful.


<bob> no

RESOLUTION: lc73 use text: if value is omitted, retry is never expected to be successful.


milo: only one and always addressed to ultimate receiver?

chair: clearly not 1 for wsa:action

<Marsh> Is the proposal to replace (mandatory) with (1..1)? Seems reasonable.

general: is mandatory 1..1 or 1..* ?

<katy> How do other specs define mandatory?

ws-context uses mandatory to mean 1..1

glen: when you receive msg, you pull out all elements targetted at you and you will only get 1 addressing property. doesn't mean there may not be another one in the header targetted at someone else.

tonyr: mandatory means "at least one", with no statement referring to maximum

<pauld> wonders if we're revisiting issue#9 http://www.w3.org/2002/ws/addr/wd-issues/#i009

tonyr: dont overload mandatory

<Marsh> Proposal: Change (mandatory) to (1..1)

chair: remove mandatory?

tonyr: no, happy to keep mandatory but qualify it with other word(s)

<Marsh> Assuming (x..y) is short for minOccurs=x, maxOccurs=y, which it seems to be.

<dhull> +1 .. 1

mandatory and limited to 1?

<plh> (1..?)

<anish> the correct set notation I think would be [1, 1]. I *think* [] implies inclusive and () implies exclusive

"We are also chartered to refine the WS-Addressing member submission which restricts the cardinality of message informational headers such as destination, source, reply, fault, action and message id to be at most one instance per message."

chair: put 1..1 in draft?

<dhull> +1 .. * to formal notation

chair: additional text for mapping to abstract bag of properties?

chair: we can write back saying 1..1 is what is meant instead of mandatory?

<bob> +1

<katy> +1

chair: any objections? none.

<pauld> recalls reading something about having multiple EPRs in the IBM Basic B2B Profile, but can no longer find it: http://www-128.ibm.com/developerworks/library/specification/ws-b2b/


<bob> -1

<TomRutt> Is there a fault for the receiver to return if they do not understand metadata?

chair: everyone comfortable to say nothing about metadata? OK




chair; is this a case of mislabeling?

chair: any objection to asking the editors to look at this?

<bob> dwr

marc: table with prop. name, description, where it goes in soap 1.1/1.2


<marc> ACTION: marc to write arun re lc57 [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action11]

Summary of Action Items

[NEW] ACTION: Glen to write proposal for lc77 [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action04]
[NEW] ACTION: Jonathan to come back with more information on lc37 [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action09]
[NEW] ACTION: Paco to continue discussion of lc107 on the list. [recorded in http://www.w3.org/2005/05/16-ws-addr-minutes.html#action07]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/05/19 18:31:15 $