W3C

Web Services Addressing WG Teleconference

24 Apr 2006

Agenda

See also: IRC log

Attendees

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

Contents


Agenda review

Bob: Reviews Agenda

Corrections to minutes

Minutes of 10th April 06

Minutes Accepted Without Objection

Action items

Bob: Can we assume that an issue submitter that does not respond to an LC resolution having been accepted?

Hugo: Yes, roughly equivalent

Proposed and New Issues

Bob: PR Issues, http://www.w3.org/2002/ws/addr/pr-issues

pr1 - mU fault one way test

pr2 - HTTP Web Method Not Specified in test documentation or specifications

pr3 - Comments on Core and Soap Proposed Recs

Bob: LC issues, 131 and 132 from Jonathan
... b4 and f2f goal to have final text with issue resolution updates

<pauld> I wonder if Mark wanted to raise a WS-Addressing PR issue. I thought he was just looking for evidence for the discussion on ImmediateDestination on the TAG list

Bob: PR issues, PR1 mU fault one way test

Jonthan: This is an issue specific to test suite

Bob: Our response this to basically inviting folks to submit tests, adequate?

Hugo: The answer we gave is fine

Bob: Proposes close issue w/ no action

RESOLUTION: Close w/ No action

Bob: PR-2 is also on test suite
... Close with no Action As well?

RESOLUTION: Close w/ No action

PR3 Several sub issues

1. The EPR abbrev is used without first defining it

RESOLUTION: Editors After first use of EPR add expansion in paren

Discussion on process for making (editorial?) changes to spec

PR3 - 1.1 It's too bad that XML Schema Component Designators

Bob: Its just a gee wiZ

RESOLUTION: No Action

PR3 - 2 Order of scetions 2 & 3

Hugo: It is a matter of preference

Bob: Ok with leave as is?

RESOLUTION: Closed w/ N Action (Annotation that spec had been reviewed for a while and acceptable to most)

PR3 - 2.1 Shouldn't that says "...this IRI is used...]?

Bob: DaveH's coment was right and we will accept that

RESOLUTION: Bob will prepare the response. No change to spec

PR3 - 3 - parties may specify -> parties MAY specify

RESOLUTION: We will take No further action (Already capitalized Appropriately)

PR3 - 3.1 References are made to the WS-A WSDL Binding spec not reached even CR yet

Hugo: Clarify that refs are not Normative

RESOLUTION: No Change

PR3 - 3.1 [relationship] In the abstract definitions it is unclear whether the

relationship type is the 1st or 2nd member of the pair.

PR3 - 3.1 [reference params] I'm sure there's a good reason but why isn't

[destination] and EPR?

Bob / Jonathan: This had been considered thoroughly already

RESOLUTION: Closed w/ No Action (will respond to author as above)

PR3 - 3.2 minor nit: why do the abstract properties and infoset reps have

different names?

Bob: Agree it would have been nice to be same, but late in the game

RESOLUTION: No Action (response as above)

PR3 - 3.2 section 3.4 describes the default for wsa:FaultTo as being

wsa: ReplyTo..and if wsa:ReplyTo is empty then it's a free-for-all.

Shouldn't this behavior be stated here?

DHull: Like above, we can be more explicit (but late in the game)

<marc> wsa:replyTo defaults to anon so hard to get empty [reply endpoint] when using our binding of MAPs to XML

RESOLUTION: No Action (Thank the author for the comment)

PR 3 - 3.2.1 why isn't comparison of [source], [reply endpoint] and [fault

endpoint] discussed?

<scribe> ACTION: Bob to produce consolidated response to Paul Biron [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action01]

Getting back to "PR 3 - 3.1 [relationship] In the abstract definitions it is unclear whether "

DHull: Since both are the same (IRI) type it is not clear

Bob: Does this cause implementation issues?

DHull: No one uses abstract for implementation

Hugo: Two options (1) Say we will fix in Errata (2) Say, did not cause problems so far

<pauld> current definition seems loose enough to be useful to me

RESOLUTION: <what hugo said for option 2>

<hugo> what hugo said for option 2 = we acknowledge that the order is not specified, but we have not encountered any problem with our implementations, and cannot foresee what this change will fix nor break, so we prefer not changing the text at this point

<hugo> (not as good as the first time I said it, unfortunately)

Bob: PR issues 1, 2, 3 Closed

LC Issues

lc124 - Conformance section

<bob> Jonathan's proposal:

<bob> Add a new section:

<bob> 6 Conformance

<bob> An endpoint reference whose wsa:Metadata element has among its children

<bob> the elements defined in [2.1 Referencing WSDL Metadata from an EPR]

<bob> conforms to this specification if it obeys the structural constraints

<bob> defined in that section.

<bob> A WSDL description conforms to this specification when it incorporates

<bob> directly or indirectly one or more of the [3.1 wsaw:UsingAddressing

<bob> Extension Element] or the [3.3 WSDL SOAP Module] markers, and obeys the

<bob> structural constraints defined in section [3 Indicating the use of

<bob> Addressing] appropriate to that marker, and those defined in section

<bob> [4.2 Action].

<bob> An endpoint conforms to this specification if it has a conformant WSDL

<bob> description associated with it, and receives and emits messages in

<bob> accordance with the constraints defined in sections [4 Specifying

<bob> Message Addressing Properties in WSDL] and [5 WS-Addressing and WSDL

<bob> Message Exchange Patterns].

Bob: Couple of +1s on the mail list
... Any objections?

None:

RESOLUTION: Proposal 1 is the accepted resolution for LC 124

<scribe> ACTION: Bob to respond to Karl [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action02]

LC 129

Paco: Describes his proposed changes

Jonathan: Like David Illsley's SHOULD change. Agree w/ March also

Marc: Prefer to change SHOULD to Can (or something), not implying any conformance requirement

Paco: I am ok with lower case should etc. if most people think so

Tom: I agree we should use english Can or something like that

<TRutt_> i like "have to rely on"

<Paco> "A WSDL or policy based service description that includes the

<Paco> wsaw:UsingAddressing but no a wsaw:Anonymous marker makes no assertion

<Paco> regarding a requirement or a constraint in the use of the anonymous URI in

<Paco> EPRs contained in messages sent to the endpoint. In this cases, endpoint

<Paco> service descriptions have to rely on additional metadata,

<Paco> such as WSDL bindings or additional policy assertions, to indicate any requirements or

<Paco> restrictions on the use of the anonymous URI by clients. However, in the

<Paco> absence of additional metadata, clients of the endpoint MAY assume that the

<Paco> service endpoint follows the behavior indicated by the 'optional' value of

<Paco> the wsaw:Anonymous marker. An endpoint SHOULD send a

<Paco> wsa:OnlyAnonymousAddressSupported or a wsa:OnlyNonAnonymousAddressSupported

<Paco> fault back to the client if a message received uses the anonymous URI

<Paco> in a way that is unsupported by the endpoint."

<bob> new proposed final version follows:

<Paco> "A WSDL or policy based service description that includes the

<Paco> wsaw:UsingAddressing but no a wsaw:Anonymous marker makes no assertion

<Paco> regarding a requirement or a constraint in the use of the anonymous URI in

<Paco> EPRs contained in messages sent to the endpoint. In this cases, endpoint

<Paco> service descriptions have to rely on additional metadata,

<Paco> such as WSDL bindings or additional policy assertions, to indicate any requirements or

<Paco> restrictions on the use of the anonymous URI by clients. However, in the

<Paco> absence of additional metadata, clients of the endpoint MAY assume that the

<Paco> service endpoint follows the behavior indicated by the 'optional' value of

<Paco> the wsaw:Anonymous marker. An endpoint SHOULD send a

<Paco> wsa:OnlyAnonymousAddressSupported or a wsa:OnlyNonAnonymousAddressSupported

<Paco> fault back to the client if a message received includes a response epr

<Paco> with an [address] that is unsupported by the endpoint.

Bob: Extra 'a' in 2nd line to be removed by editors

<TRutt_> s/in this cases/in this case/

Paco: Above Text resolves part of LC 129

Jonathan; Was there a concrete proposal for the rest?

Paco: We were expanding Proposal 4 (original)

Jonathan: "Remove the

default. Lack of wsaw:Anonymous means there are no claims about Anonymous

support.")

RESOLUTION: Closed Issue 129 with the above resolutions

LC 131 UsingAddressing and soap:mustUnderstand

Jonathan: Describes his proposal

Paco: Agree w/ Jonathan to remove the 3rd column in table 3-1

RESOLUTION: LC 131 Closed w/ resolution to remove 3rd column in tbl 3-1 and collapse rows 1&2

LC 132

Reference Parameters vs. complete EPRs

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Apr/0030.html

Jonathan: Describes proposal

MarcH: I sent some change suggestions

Jonthan: Take those as friendly amendments

<bob> "A wsdl20:endpoint or wsdl11:port element MAY be extended using a

<bob> child wsa:EndpointReference element. When extended this way, the

<bob> [address] property of the child EPR must match the {address} property

<bob> of the endpoint component (WSDL 2.0) or the address value provided by

<bob> the relevant port extension (WSDL 1.1). For example, in a SOAP 1.1

<bob> port described using WSDL 1.1, the location attribute of the

<bob> soap11:address element must have the same value as the wsa:Address

<bob> element."

RESOLUTION: LC 132 Closed with Jonthan's Proposal, w/ amendments in MarcH's email (URL above) \

as shown in-line above in the last paragraph

<scribe> ACTION: Bob to update the issues list with the consolidated proposal [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action03]

<scribe> ACTION: MarcH to coordinate w/ Tony to produce updated WSDL bindig Doc final text by April 28 06 [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action04]

Discussion regarding upcoming F2F

Bob: AOB?

Meeting Adjourned

Summary of Action Items

[NEW] ACTION: Bob to produce consolidated response to Paul Biron [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action01]
[NEW] ACTION: Bob to respond to Karl [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action02]
[NEW] ACTION: Bob to update the issues list with the consolidated proposal [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action03]
[NEW] ACTION: MarcH to coordinate w/ Tony to produce updated WSDL bindig Doc final text by April 28 06 [recorded in http://www.w3.org/2006/04/24-ws-addr-minutes.html#action04]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/04/27 00:48:30 $