Web Services Addressing Working Group Teleconference

23 May 2005


See also: IRC log


Andreas Bjärlestam (ERICSSON)
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.)
Hugo Haas (W3C)
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)
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)
Steve Vinoski (IONA Technologies, Inc.)
Katy Warr (IBM Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Abbie Barbir (Nortel Networks)
Dave Chappell (Sonic Software)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Philippe Le Hégaret (W3C)
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.)
Mark Nottingham
Nilo Mitra


<scribe> scribe: Nilo

f2f planning

last week's minutes

minutes approved

minutes of may 16, that is

action item review

lc 60, 65 to be done

lc106 done

the wsdl part will be taken to the wsdl wg

f2f planning

room size discussion

internet access on thu but not on fri; lunch will be provided

Mark considering cancelling monday jun 7 telcon; will decide at the f2f

lc issues


anish: should these be message addressing properties?

comment 1: editors will do the right thing

comment 2: agreed

<bob> agreed

comment3: hugo? says that the propsed language is becoming very specific

it make it difficult to use eprs for anything other than invokeing web services

<TomRutt> OK with the nits present

call this editorial and leave it to the editors to use this proposal to clarify "consuming application"

comment 4: use pre-defined

comment 5: anish: is this for consistent formats for uri

jonathan: should be consistent but also short

mark: could flatten the uri space

marc: would change message id and anonymous

jonathan: alternative proposal - remove ../id/.. and call it unspecifiedID

marc: leave it to the editors to finetune

jonathan: unspecifiedId

accept comment 5 and give it to the editors to shorten the uris

comment6: marc: this is wrong as this uri is for adderssing faults and not a generic soap fault

comment 6: no change

comment 7: tom: seems like it would be a large list of things a sender would or wouldn't have to do

<uyalcina> +1 to tom.

comment 7: is there isn't some proposed text by the f2f, then close this item with no change

<mnot> ACTION: Nilo to provide example for comment 7 of lc89 by june 1st. [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action01]


lc91, comment 1: agreed

lc91, comment 2: agreed

lc91, comment 3: mark: we have some unresolved intermediary issues

jonathan: this isn't about intermediaries

glen: but it enables support for them

anish: just because role = next and relay=true doesn't mean that it is targeted at the ultimate receiver....

tom: is there a conformance test that can be done

<mnot> Current text: When sending a message each property is represented using the appropriate element information item as a SOAP header block. The resulting header blocks are targetted at the ultimate recipient in the SOAP message path (note that extensions to WS-Addressing could be written to specify different targetting). 3.4 Binding Message Addressing Properties describes additional processing required when binding message addressing properties to SOAP header blocks.

marc: the abstract description does not talk about targeting

we could add something to the abstract spec to talk of targeting

tom: could something nromative we could say to disallow certain types of targeting

marc: do we need to address that nothing in the sentence is normative

david: isn't it generally true of soap that the defaul targeting is the ultimate receiver

anish: we decided to allow multiple copies of the same headre targeted to different roles. so we allow targeting of headers

marc: you need an extension to show how you have multiple To:

mark: leave it for the intermediary discussion

<anish> +1 to relay

comment 4: marc: it should be relayed, not replayed

marc: this text is essentially the saop processing model

comment 4: replace "replayed" with "relayed"

comment 5: mark: have we done something here already?

comment 5: accepted

for lc89 and 91 we have deferred two comments. No need to send email to Nilo


jonathan gives some explanations

anish: if there is %escaping, nothing would change

jonathan: yes

lc105 accepted.


jacek is objecting to having action as mandatory

mark: see nothing new here; discussed these points during i031

tom: requirements on the sending application may state what the action uri should be

<anish> i agree with Jacek to make [action] optional, but i agree that this is an issue that has been already resolved

maybe the wsdl has some statements on how to put this

umit: jacek doesn't like this action uri; he ahd some problems in wsdl

tom: are there any constraints on the sender to put a particular value there? if the wsdl has a value, does the sender have to put that value there?

are we very clear on what the sender should do?

jonathan: don't have our conformance statements for wsdl done yet

mark: no new information; ack Jacek that we aren't going to change the spec

<uyalcina> +1 to tom :-)

mark will respond to jacek

<mnot> ACTION: mnot to write back to jacek on lc70; no new information [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action02]


anish: are these SOAP headers?

yes, a SOAP 1.1 header

anish explains how SOAP1.1's fault is signaled

jonathan: would like to defer this

editors find this quite straightforward; but this is deferred to next week


action to think through this and come back next week

anish takes the action

<mnot> ACTION: Anish to look into lc72 and report back by 2005-06-01 [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action03]


marc: agrees with this

jonathan: would like to see just [action] not the whole string

mark: need to clarify the template a bit, and then deal with the different languages

jonathan: might be the [detail] element which takes the value of the action property

mark suggests that jonathan work with the editors.

no one objects

<mnot> ACTION: Jonathan to work with editors to clarify templating language in soap faults. [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action04]

mark: the next issue is whther this is required or optional

anish: this is english language element

jonathan: should it always be english, or if it is english it should be "..."

jeff: just say natural language

<Marsh> "[Reason] The English language reason element."

jonathan: clarify that this is the text that should be used when the language is english

marc: the reason element is M in SOAP1.2

anish confirms that it is M in SOAp1.1

lc71 closed with no change to the optionality of the reason; some editorial cleanup will be done

katy will respond to author


david: every error condition should have its own error code

this is not meant to be a complete set

jonathan: should there be a unique error for every MUSt in the spec?

david: there should be some normatievly specified way to tell what happened

umit: it looks like you need a subcode of the first fault rather than separate faults

<anish> concern about subcode -- SOAP 1.1 does not have subcodes, so mapping to soap 1.1 would be problematic

tom: we seem to be getting into reliable messaging

<bob> +1

david: not religious about how this is realised; just want it to be unambiguously identified

jonathan: seems reasonable; but could be more than we need; may have to go through the whole spec and look at all the MUSTs

mark: can the editors do this?

jeff: as a group we should decide on the policy/concept

jonathan: would like a point by point changes from the editors as a result of this

marc would prefer someone else do it

david will try to produce a definitive list of conditions which generate a fault and what to do.

<mlpeel> +1 to umit

umit thinks this is a good idea; will need it during testing

<mnot> ACTION: David Hull to come back with detailed proposal, with effects on other parts of the spec, for LC76 [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action05]


jonathan: a conformant ep should act in conformance to the spec, but if you don't send any wsa headers our spec will be silent on the behavior

tom: in wsdl spec we will have conformance statements, but we are talking about the core here
... need some statement in the core

david: ;look in section 3.2 of core

tom: an epr aware client will use wsa headers, but you don't want the ep to use eprs necessarily

<uyalcina> haven't we covered this already?

umit: may have been covered when we discussed wsdl=required

david: if someone gives me an epr, sender is not required to use wsa headers

umit: wsdl is one particular policy, but there can be other policies taht can determine how you use that epr

david: nervous about the potential leeway allowed

tom: as long as the text allows it, he is OK with it. No need to list everything one can do.

david: concerned about the precision and clarity of the text

anish: why is this a concern? if you are not using ws-addr, this spec has nothing to say about it

david: there should be leeway for sender to use ws-a headers without understanding ws-a

jeff: the spec can't prohibit you from doing anything it doesn't talk about

tom: close it with a statement in the minutes that says this is allwoed

lc61 closed with no change and it is allowed


david: we should explicitly talk about message versus end point compliance

mark: we have a lot of conformance issues; we should leave it open until all are sorted out

lc62 deferred until next week

lc 75

lc88 is related to it.


mark: surprised by lc88 that you can reuse message id for retransmission

tom: reliability has specific things to say about retransmission

mark: message ids have many uses

david: subtle issues involved; by making them unique in space and time takes a very definite position

tom: is there any issue on the optionality of message id?


tom: keep them separate

david: this is up to the sender of the message and his deployment environment; cannot have the receiver do the uniqueness constraint

it should be up to users of the spec to decide how to use it

bob: concerned with language; a retransmitted message has a different id, but if it is part of a digest there is a cost

find the language problematic

david: differnt application intent relaxes the uniqueness requirment

he'd like to see a SHOULD; may be reaosns in a deployment not to be so strict

bob: primarily objects to the "and time" issue..why not just say "unique"

tom: need to say something here about retransmission

agrees with bob re time

has to be unique except for retransmission

david: that why SHOULD is preferable, because of retransmission

<mlpeel> Retransmission is (or should be) transparent to WS-Addressing

bonb volunteers to put a definition of uniqueness

<mnot> ACTION: bob to propose combined resolution of lc75 and lc88 [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action06]

jeff: need the right level of abstraction, it isn't about retarnsmission of packets

meeting adjourned 6 pm est

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/05/25 18:44:23 $