Web Services Addressing WG Teleconference -- 24 Apr 2006

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: