Web Services Addressing Working Group Teleconference

27 Jun 2005


See also: IRC log


Abbie Barbir (Nortel Networks)
Rebecca Bergersen (IONA Technologies, Inc.)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Martin Gudgin (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
David Hull (TIBCO Software, Inc.)
Anish Karmarkar (Oracle Corporation)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
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)
Pete Wenzel (SeeBeyond Technology Corporation)
Prasad Yendluri (webMethods, Inc.)
Andreas Bjärlestam (ERICSSON)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Amelia Lewis (TIBCO Software, Inc.)
Paul Knight (Nortel Networks)
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.)
Steve Winkler (SAP AG)
Marc Hadley (Sun Microsystems, Inc.)
Yin-Leng Husband (HP)
Nilo Mitra (ERICSSON)
Ümit Yalçınalp (SAP AG)
Mark Nottingham
Mark Peel


No corrections to minutes; no objections to approving minutes of June 20.


<mnot> Request: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0104.html

<mnot> Anish's Response: http://www.w3.org/mid/42B8A1F0.9070407@oracle.com

<mnot> "The Addressing Working Group does not have additional requirements for the deliverables mentioned, but may have additional requirements for other, related deliverables in the near future. The WG believes that XMLP should commence development of the one-way MEP and binding, as the additional requirements are likely to be orthogonal to the delivery of them."

Discussion of whether the requirements to XMLP were clear enough and whether possible future requirements would indeed be orthogonal.


lc90: Paco: this is a valid way of doing things and we should close with no action.

dhull: we all agree we need a nonce to prevent replay attacks.

dhull and paco discussed what the spec was actually saying about using MessageId to determine uniqueness.

dhull doesn't like messageID + timestamp as a nonce; he would like the sentence recast to eliminate ambiguity

<mnot> chad, option 2: close the issue with no action

<Marsh-backup> Add "In this case, " to the start of the 2nd sentence

<pauld> chad, list options

Proposal: add "In this case" to the start of the 2nd sentence; no objections

RESOLUTION: Close lc90 by adding "In this case," to the beginning of the second sentence in the existing paragraph.


<Zakim> dorchard, you wanted to ask about "understanding"

Jonathan, after consulting internally, thinks this a big design change -- too big for the time we have

GlenD: I don't think we have to go as far as Jonathan is worried we'd have to. We could leave the portion about including WSDL rather fuzzy -- but mandatory.

Anish: agrees this is not time-consuming and would be a good thing to put in the spec.

mnot: a previous issue covered this point; do we really need to re-open this?

<dorchard> BEA has changed it's mind on this issue.

<GlenD> +1 reopen

<TonyR> happy to leave un-re-opened

<RebeccaB> +1 reopen

<dorchard> +1 to reopen after more discussion with my various eng teams

<Marsh-backup> Stay out of the trout pond - keep it closed.

<dhull> +1

Poll: should we re-open the issue about adding mustUnderstand

<anish> +1 reopen

<TomRutt> reopen issue

<pauld> please, no

<jeffm> yes

<TomRutt> +1 reopen

<vinoski> +1 reopen

<jeffm> +1 reopen

<Paco> -1

<pauld> -1

<bob> -1

<TonyR> -1

-1: leave it closed

<Marsh-backup> -1!

<Katy> 0

<GlenD> Alas, this will entail moving forward with a formal objection. :(

mnot: we had a clear direction on this before and it's contentious, so we should leave it closed.

<Marsh-backup> Gudge says "file -1 for me too"

<TomRutt> on LC 68 : the unclarity semantics of "extensibility" of epr, lead me to want to reconsider the use of a mustUnderstand on an EPR extension

<scribe> ACTION: Jonathan will write Jacek and explain why mustUnderstand will not be added to EPRs [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]

RESOLUTION: Closed with no action.

lc20 Clarify anonymous URI

<mnot> Some transport bindings, notably SOAP/HTTP, provide a means of returning a message directly to the sender of that message, regardless of its contents. To allow for direct use of such a facility, WS-Addressing defines the URI "http://www.w3.org/@@@@/@@/addressing/sender" to indicate that the destination is the sender: This URI MAY be used as the [address] of the [reply endpoint] and/or [fault endpoint] addressing property, but SHOULD NOT be so used if the transpor

<mnot> n not to provide a return facility.

Jonathan: dhull's proposal seems to go beyond the original meaning

dhull: if there are other cases, we should handle them separately

Jonathan will do more research; issue goes back to the list.


Anish didn't get to this


Remains pending


Anish doesn't think there's an issue(s) here any more; recommends closing with no action

Can we close lc103 with no action? No objections

RESOLUTION: Closed with no action.


<mnot> http://www.w3.org/mid/OFEC611FCB.8E34C4A2-ON8525700A.000C2A6E-8525700A.0014723F@us.ibm.com

<mnot> http://www.w3.org/mid/1191ECEA-0CEB-47B0-B915-BA21B2F8D196@Sun.COM

Marc proposed using "message" and "reply"; this would not change Anish's stance on lc103

dhull: "reply" seems confusing because of "ReplyTo" and "FaultTo"
... "response" seems preferable, but explanation in text is acceptable.

No one objects to Marc's proposal

RESOLUTION: Use "Message" and "Reply" instead of "Request" and "Response", with a qualification of the scope of "Reply"

<mnot> ACTION: Jonathan to communication resolution of lc107 back to WSDL WG [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]


<mnot> http://www.w3.org/mid/OF327F07CB.D3861A9C-ON8025702D.005C5BD8-8025702D.005E3A7C@uk.ibm.com

Katy: runs through proposal for a "no reply" URI that can be used in replyTo EPRs
... alternately, we might define a "not valid" EPR for use with reply, fault, or source endpoints.

TomRutt: is this at the sender's discretion or would it be required at all? Katy: NoReply is a runtime decision

Paco: this is just a different way of expressing things, like omitting an endpoint; it may be a good compromise proposal.

<TomRutt> I wuld like to clarify that I could accept the IBM proposal if it was left to the client whether it is used or not.

Katy: this allows a default of the anonymous URI for omitted endpoints

dhull: is this aimed at the request/response or the one-way case? Katy: both

Paco: replies are not limited to the WSDL MEPs, so one-ways may come in answer to one-ways

TomRutt: would like to see this taken to the email list because of the lengthy discussion

<Zakim> dhull, you wanted to ask what part of WSA is affected by the one-way semantics

dhull: is this all in the context of section 3.3 or is more general? Katy: this affects the re-opened i50, so I think it affects only the section about formulating a reply.

lc87 and lc55

<mnot> http://www.w3.org/mid/646CD56A-3711-44EB-8EDA-44257F15349E@Sun.COM

Jonathan: we had some concerns about a security section having SHOULDs: security are advice, not normative

<dhull> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

mnot: that may be true in the IETF, but it may not be the case for the W3C

Jonathan: otherwise we support Marc's proposed text.

<Marsh> Believe SHOULD vs. should is pretty much editorial...

Paco: still looking for feedback.

mnot: if there's no feedback by the next meeting, we'll re-open i4 and approve this text.

lc76 supported faults

<hugo> http://www.w3.org/mid/42B71FBA.5060804@tibco.com

<mnot> ACTION: David Hull to continutally refine lc76 proposal to reflect other changes; make into spec text [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]

mnot: adding subcodes does not seem like a substantial change (this in response to a concern that changing this section exposes WSA to another Last call

lc5, utility of [source endpoint] unclear

mnot: should we leave it in without comment, leave it with test cases, or identify it as "at risk"

<Zakim> dhull, you wanted to point out this may mesh with "return to sender" rule.

mnot: marking it as a feature at risk leaves our options open; we'll revisit this after the other issues are closed.

Summary of Action Items

[NEW] ACTION: David Hull to continutally refine lc76 proposal to reflect other changes; make into spec text [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]
[NEW] ACTION: Jonathan to communication resolution of lc107 back to WSDL WG [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]
[NEW] ACTION: Jonathan will write Jacek and explain why mustUnderstand will not be added to EPRs [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/28 23:35:32 $