Web Services Addressing F2F -- 20 Apr 2005

i055

JM goes through sample RDDL document

JM shows RDDL showing latest schema, previous schema

The owner of an XML namespace name SHOULD make available material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace vocabulary.

<hugo> http://www.w3.org/2001/XMLSchema

<hugo> [[

<hugo> hugo@buena ~% HEAD http://www.w3.org/2001/XMLSchema

<dorchard> Schema returns application/xhtml+xml

<hugo> [..]

<hugo> Content-Type: application/xhtml+xml; charset=utf-8

<hugo> ]]

no objections to using rddl

RESOLUTION: group accepts Jonathan for issue 55

i021

Group examines Paco's proposal for issue i021

Mark: JM made a proposal about conformance of messages and endpoints to addressing.
... Is this flag indicating conformance?

Glen: extra work to specify what's being done/not being done, and asynch doing in broadly applicable way

Paco: Not sure if anything has to be disabled in bindings by wsa use
... my proposal has required=true
... I'm not firm on this. required=false means bindings are "two-headed"

DaveO: this allows existing asynch unaware clients to continue to work.

Glen: required=true means for the binding is that action and To are required.

prasad asks about versioning.

prasad: what if wsdl binding versions, does that mean everything else versions.

paco: pushes back on not versioning marker

daveo: what about errata, minor changes? Change version always.

paco: move 3 specs together.

prasad: I raised a new issue on the versioning and namespace semantics per the action on the last WG call

paco: goes through proposal.

<prasad> We need to explicitly state in the text that describes this marker that this is applicable to all WS-A specs. When the marker is present any of the constructs from all three WS-A specs may be used.

Glen: we should allows required=false

seems to be agreement with Glen in group

glen: required=true means agreeing to semantics as defined by specification.

GregT: boolean isn't quite right.

Glen: required=false means it's your choice

paco: if I do the 2 bindings approach, then responses won't have ws-a info in the "non-wsa".

daveo: if wsdl:required="false", and headers are returned, they ought to be marked with s:mU="false". If they would be marked with mU="true", then wsdl:required=true should have been specifiied.

paco: yes.
... next point, where does the marker occur in the binding

Glen: per op may be useful..

GregT: difficult to map to programming languages..

Group agrees to restrict scope to just binding.

Glen: maybe marker is shorthand for a soap:module?

Paco: rewrite to refer to wsdl: required.
... have to go into the case

<hugo> Proposed text: In WSDL 2.0, the wsoap:module construct may be used to declare the use of WS-Addressing 1.0 for the SOAP binding. The meaning of wsa:UsingAddressing is semantically equivalent to such a wsoap:module declaration in this case.

<GlenD> sure

<GlenD> although you might want to switch it and say "the meaning of the soap:module declaration is semantically equivalent to the wsa:UsingAddressing...."

<hugo> wsoap:module is allowed in binding, operation, input, output, infault, outfault, fault

<hugo> see http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#soap-syntax

Umit, IBM want first message to determine the response message's use of wsa headers. If first msg has no wsa, response won't.

Glen wants to enable optional support to mean response could always have wsa headers.

Discussion about should wsdl:required="false" allow wsa:headers s:mustUnderstand="true" to be returned.

Some folks want to disallow this case.

back to mU=false.

Umit: pushes back that some impls are faulting if they see mU="false".

Paul: mU rules don't help at the app layer.

Pasting in the Hugo text.

prasad: how should this spec talk about the multiple specifications and/or namespaces.

MarkN: what about other soap bindings?

DaveO: then the "new" soap binding would say in a new marker how it was engaged.

<GregT> WSDL 1.1 and 2.0 Web service descriptions for endpoints that follow the WS-Addressing specification, MUST indicate this fact using the <wsaws:UsingAddressing> extensibility element defined in this specification. The wsdl:required attribute MAY be used to indicate whether WS-Addressing message information headers are required in messages received from service requesters.

<GregT> When wsdl:required is set to "true", both request and response messages exchanged with the endpoint MUST contain WS-Addressing headers. When wsdl:required is set to false, the endpoint MUST accept request messages with or without WS-Addressing headers and response messages in that case MAY contain WS-Addressing headers; if WS-Addressing headers are not present in the request, and a SOAP binding is used, WS-Addressing headers encoded in the response MUST NOT be

<GregT> marked with soap:mustUnderstand=true.

Glen: WSDL goes out into the world, the next version of service supports ws-a, is old wsdl invalid?
... picks away at the "MUST" indicate this fact portion.
... would like it to say "CAN" or "MAY"

Paco: what about scenario where ws-a required but why would you not say?

Glen: this should say something like "using the usingaddressing element OR the soap module"

daveO: Paco, do you want MUST use the element if incompatible change and MAY use the element if compatible?

Paco: If compatible change, then MAY use marker and if you do use the marker then required="false". If incompatible, then MUST use marker and must be set wsdl:required="true"

JM: conformance issues around wsdl binding and this text.

Glen: when doing this stuff, make sure that the contracts are reasonable, like wsdl. And here's a marker in WSDL.

DaveH: remove the sentence on wsdl:required as it doesn't help with clarity

lots of discussion about wsdl:required..

Rewording to list the possibilities by required="true" and then required="false" order

DaveH: what about if Action Property present but is not sent as a header block.
... if you look at message through old eyes, just http:action. If you look at it with wsa eyes, then wsa:action.

Paco: existance of wsa:action is always required, that can be the trigger to indicate wsa being in use.
... to claim conformance with wsa, you MUST indicate if you are using WSDL.

<Marsh> This specification provides mechanisms for indicating in a WSDL 1.1 or WSDL 2.0 description that the endpoint conforms to the WS-Addressing specification.

JM: WSDL 2.0 says something like you should provide an accurate description.

Glen: you can test the "provide a wsdl" and then test

Paco: trying to catch the wsdl didn't say ws-a yet ws-a was required case

anish: can you conform to core without soap and claim conformance?

umit: quotes wsdl 2.0 spec on conformance and required usage.

<hugo> Scribe: Hugo

Anish: what does the last sentence mean when I'm not using the SOAP binding?

Mark: Hugo took an AI to provide text on this

Anish: but that's specific to the SOAP binding; what if I'm *not* using the SOAP binding?

[ discussion postponed until text about SOAP binding is shown ]

<mnot> WSDL 1.1 and 2.0 Web service descriptions of endpoints that conform to the

<mnot> WS-Addressing specifications SHOULD indicate this fact, and MUST do so when

<mnot> they require conformance to WS-Addressing to operate.

Straw poll on including the "MUST" part: 8 for

<abbie> can u add me

Other text proposed is "This specification provides mechanisms for indicating in a WSDL 1.1 or WSDL 2.0 description that the endpoint conforms to the WS-Addressing specification."

<MSEder> Abstain

Same straw poll (having the "MUST" part of the text): 9 for, 4 against, 9 abstaining

Proposal A: "WSDL 1.1 and 2.0 Web service descriptions of endpoints that conform to the WS-Addressing specifications SHOULD indicate this fact, and MUST do so when they require conformance to WS-Addressing to operate."

Proposal B: "This specification provides mechanisms for indicating in a WSDL 1.1 or WSDL 2.0 description that the endpoint conforms to the WS-Addressing specification."

<MSEder> Abstain

Straw poll about A and B: 7 for A, 10 for B, 6 abstaining

Mark: does anybody feel strongly enough about this to have more discussion?

[ silence ]

<inserted> Mark: Moving to the SOAP text

Proposed text about the SOAP binding: "When applying to a SOAP binding, the <wsaws:UsingAddressing> marker identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by [@@link to SOAP Binding spec@@]."

Mark: [addressing Anish's concern ] the WG went in the direction of having the marker talk about things defined in our specs

Jonathan: this brings back the problem that the core is difficult to conform too
... you need concrete artifacts, which basically means the SOAP binding

Anish: what does conforming to the WSDL binding mean?

Jonathan: the presence of the marker means that you are conforming to the SOAP binding

Anish: to me, we mean conforming to all the 3 specs
... if we think that other bindings are possible, which I think is true, it would be nice to provide them with a framework
... I was thinking of a marker which means that you conform to core
... and you could have a child element which says that you conform to the SOAP binding
... and we could make this extensible

Paco: there was no intent to restrict the marker to SOAP

Jonathan: but his point is that you may want to have a different binding

Anish: I think that we should provide such an extensibility point
... in any case, I think we should clarify that we don't limit the marker to SOAP

[ change being made on the screen ]

Anish: there are lots of optional properties in the core
... the service may require you to use certain of those

Mark: we have open issues about this, especially i058

Anish: I heard Paco say that using the marker means that the service recognizes WSDL-related metadata
... let's say that Reply-To is required, and I stick WSDL-related metadata in there
... will the recipient process it

Mark: we don't define a processing model

Jonathan: what if I put in Jonathan's metadata? what will you do with it?

Anish: we don't talk about it in our spec
... I see, there's nothing we can say

Mark: are we happy about the text?

Hugo: the wsoap:module text needs to specify which module URIs we're talking about

[ note added for the editors to fix this ]

DaveH: I'm not sure that this text completely addresses i021

Mark: we have other issues that will add more features to the WSDL binding

RESOLUTION: proposed text on the screen accepted as the resolution of i021

<TonyR> scribe: TonyR

Issue 56 (non-last call)

Determining the [destination] property from WSDL

Discussed the 5 proposals on a call, but not resolved

Leaning towards 4 or 5

marsh: positing the existence of a WSDL without an address, plus an EPR containing the address

glen: doing this in one of the JSRs

anish: would expect the address in the WSDL to override the EPR, if both are given
... the transport address in the WSDL

general discussion of physical vs logical address

scribe: logical address from EPR
... physical from WSDL

Marsh: if WSDL does not contain address, may get address from a degenerate EPR

anish: this is addressed by issue 20, subissue 3

umit: do not like confusion between EPR and WSDL, particularly considering a WSDL containing an EPR...

anish: started with that idea, when writing proposal 1 and 2

marsh: happier with proposal 4 if you can put an EPR in a WSDL but without metadata?

anish: wouldn't be consistent, anyway

umit: (unconvinced)

marsh: prefer: if you have both, EPR wins

glen: if EPR contains an address in TO, that must be the address
... but that doesn't deal with addressing

marsh: if there is nothing else specifying where to send the message, use the address in the EPR

mnot: you mean "a child element" not "the child element" in proposal 4?

anish: yes
... that's for Marc to tidy up.

paco: value of the address in the EPR only affects the value of the TO header in messages

marsh: yes

<uyalcina> i was suggesting we have either an address or an EPR, but not both

marsh: no reference parameters, etc

rebecca: how does this affect the parameter which points to the WSDL?
... does this replace it?

anish: no - it wouldn't make sense to use it in that case

Clarification: I was trying to say, when there is no EPR in the WSDL, only the To gets set.

chair: is everyone reasonably happy with proposal 5 - seems the way we are heading?

umit: why do we need this complexity?

glen: can specify an address in the WSDL for despatching, give address in the EPR for destination

marc: confirming the meaning of the proposal

anish: this comes into effect when addressing is added to the mix with WSDL

paco: we will be effectively doing physical/logical addressing, even if we don't say it - perhaps we should say so?

umit: don't like that

chair: focussed on proposal 5

omnes: yes

chair: is the group happy to have the editor/s word smith it?

marc: willing to put the words into the spec, group to review

<abbie> yes for me

paco: a last question: if you only have one address, do we use it for both physical and logical address?

<uyalcina> +1 to Paco

umit: want to amend proposal 5: if the WSDL contains an EPR with metadata which points to a WSDL that contains an EPR...

omnes: !run and hide!

chair: let Marc write this up and we will review next week

glen / anish: the TO is not the "physical" address

marsh: don't want to call it the physical address

glen: if you get an EPR from another source, it's up to you what you do with the address

marsh: if this is so useful, why don't WSDL or addressing include this idea?
... why does this only come up when using addressing and WSDL together?

anish: disagree with the premise - can be done with addressing only
... what is being raised is Issue 20

<scribe> ACTION: Marc to write a more complete proposal for proposal 5 of issue 56 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action06]

Issue 20, subissue 3

anish: the previous discussion doesn't alter this issue, but has the same problem as was being discussed.

paco: if we go the direction of the physical address is in the WSDL, then the EPR cannot re-direct via the replyto

marsh: if we receive an EPR during a conversation where we have been sending messages to the address in the WSDL, does the EPR
... redirect us, or do we simply add the EPR address to the TO header, but continue to send to the address in the WSDL?

anish: know via some out-of-band mechanism

marc: couldn't you omit the soap:address and use an EPR?

marsh: so we leave the address out of the WSDL and need to send an EPR before starting the conversation?
... don't want to ship a complete new WSDL just to replace the address

marc: sounds like different things: design time overwrite vs run time overwrite

anish: conflicting requirements: the address in the WSDL can be overridden by the EPR / WSDL overrides the EPR

glen: how about disallowing both?

marsh: so if I ever want the ability to redirect, I must use an EPR

chair: are we revisiting issues that have been discussed and settled?

glen: disallowing both solves the problem, but doesn't allow earlier possibility (uding a despatch point via WSDL address).

Marc: perhaps if you specify both, they must have the same value.

<uyalcina> +1 to Marc

Dave: if you have both, the client may choose either?

?: might want both to service a non-addressing-aware client

anish: they are not the same.

marsh: if they are not the same, WSDL 2.0 should deal with this.

chair: if people want to make them the same, this modifies issue 56

marsh: use the address to set more than the TO header - do something more.

anish: not convinced that they should be the same

marsh: should the values expressed in the two syntaxes be the same?

straw poll: should the values be the same? Yes: 7, No: 0, Abstain: 15

<scribe> ACTION: 1 to Marc to draft a proposal to address issue 56 (reflecting his prejudices), dealing with the values of the address properties [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action07]

Issue 20 (again)

chair: does the discussion affect issue 20?

anish: yes.

chair: wait for 56 to play out before addressing issue 20

issue 57

dealing with reference parameters

NOTE: there will be no meeting next week - too many people will not be available

anish: wait for issue 56 and 20 to play out first.

Issue 58

defining MAPs in WSDL service descriptions

anish + paco: can discard source, reply endpoint, action, message id

must consider fault endpoint, relationship

glen: faults - might want to send all faults to a central point

chair: there may be use cases for fault endpoint & relationship - do we want to support these in WSDL?

anish: may wish to specify relationship statically in unusual MEPs (eg: out-in-out)

marsh: could handle this with a WSDL extension?

anish: correlating two one-ways using a relationship in the WSDL

marsh: but the relationship is a dynamic property, one of which is run-time

anish: couldn't use property directly - need some replacement technique, with the WSDL specifying the non-runtime IRI
... describing a technique using two operations

chair: possible use case, but questionable if there's if enough will to follow this up.

chair: perhaps we can close this. If there's a need, we can deal with under issue 59

chair: looking for someone to write up the resolution

<scribe> ACTION: Jonathan to write up the resolution of Issue 58, explaining reasoning behind each [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action08]

Issue 17

<scribe> ACTION: Anish to write a new proposal for Issue 17, including the new information [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action09]

issue 59

Supporting async

report from the async task force: glen (chair of TF)

glen: summary of discussions, comments invited
... in Melbourne DaveO presented on the use of various MEPs on various transports
... acknowledged need for supporting async comms
... useful if all the async comms worked in a standard way
... most basic case: send a request with a replyto on HTTP, get back a 200 OK, later receive response on a fresh HTTP connection (replyto).
... began by soliciting use cases - six or seven use cases - can we meet these with current facilities? If not, what do we need?
... three layers: SOAP / WSDL / WS Addressing - which do we change?

<anish> http://www.whatfettle.com/2005/04/wsa-diagrams/

glen: we have come to the conclusion that we need something at the SOAP MEP level
... how do we make in-out over a one-way transport (eg: UDP)?
... note: that the diagrams (link above) omit the specification of replyto / faultto.
... (talking to the diagrams)
... in talking about a channel which has a back-channel, we need to consider whether a message will travel on the backchannel
... in the diagram, A shows reply on backchannel; B shows it coming back on in a separate message
... important thing is that sometimes you have a backchannel (HTTP), sometimes you don't (UDP, SMTP).

anish: (questioning the relevance of the backchannel)

glen+dave+tony: (describing reasoning for considering the backchannel)

<pauld> tony's timeline for when a replyTo channel is understood: http://www.flickr.com/photo_zoom.gne?id=9877189&size=m&context=set-241663

glen: describing layering of communications.
... Monday's meeting agreed that we require the ability to represent one WSDL MEP as more than one SOAP MEP

umit: there was considerable discussion about the ability to limit interchange to A or B

dave: and that there may be cases where you don't know which

rebecca: considering cases other than SOAP?

glen: definitely
... the important case is that there may be mapping taking place - one WSDL MEP may be mapped to multiple lower interchanges

paco: the fact that the programming model looks synchronous "on top" will not stop the underlying support being asynchronous.

glen: an apparent single request / response at a higher level may get implemented as multiple request / response interchanges underneath
... in-out in WSDL means nothing more than correlated request-reply messages

marsh: made everything outside the single in-out MEP out-of-scope

glen: the Monday meeting discussed timing issues about when/whether one might take advantage of the back-channel for returning a fault, even though the FaultTo has been processed.

daveo: this backchannel discussion (see diagram pointed to above) is still open
... a possible approach is an "allowsAnonymous" flag to indicate that the backchannel may be used.

glen: another is the "fastClose" hint that indicates that the backchannel should be closed as early as possible

dave: a not-very-async server (holds backchannel open a long time) - its HTTP OK may mean all went well.
... a more async server's HTTP OK just means backchannel closed

marc: how do we tell these apart?

glen: that's got to be policy, or some other setting
... we need to figure out how these things are specified

dave: the question of whether a server will accept requests that do not include a replyTo (no replyTo means use backchannel)

daveo: there is the case: a server will not accept requests without replyTo
... not even with anonymous

glen: if we have a concept of a flag that indicates whether the binding has a backchannel

greg: was the polling model discussed?

glen: we did not discuss that model

marc: minimum amount of processing would be mustUnderstand & addressing processing before can decide to be async

glen: not necessarily - if there was a flag saying "will never reply on backchannel", then no.
... will be able to close backchannel immediately on receiving message.

daveo: need a new HTTP binding, or modify existing one.

glen: need to explain how to support one-way, either on existing binding, or using a new one.

paco: would it make sense to represent this in a WSDL 1.1 binding? To see how it works on the wire, before we try to get it in WSDL 2.0?

glen+dave: trying to decide which SOAP MEPs we require.

paco: can we bypass the SOAP MEPs by trying it in WSDL 1.1?

anish: summary: 1. need ability to have one WSDL MEP from multiple SOAP MEPS; 2. need new HTTP binding or modify existing one

glen: yes, but not just HTTP - there are other protocols that have a backchannel

anish: like the approach Paco is suggesting - solve the SOAP 1.1 / WSDL 1.1 problem now, take that forward to SOAP 1.2 / WSDL 2.0

<dorchard> Paco, kind of like the examples in http://dev2dev.bea.com/webservices/WS-CallBack-0_9.csp

glen: because we have an idea of what we want on the wire, let's try to develop WSDL 1.1 markup to produce that result

umit: this is simpler, because we can ignore the more esoteric MEPs

?: have the TF members agreed on the wire content?

glen+daveo: pretty much - there are some minor items to sort out

anish+umit: we need not solve the SOAP MEP problem before doing this

glen: there are other questions yet to be resolved
... things like the ability to specify that a server supports ReplyTo on both HTTP or BEEP
... how do we limit replys to those two protocols?

paco: perhaps we should solve the simpler cases first - particularly the HTTP + WSDL 1.1 + SOAP 1.1

glen: the way forward is to nail down a specific scenario during the next telecon (two weeks time)

daveo: perhaps we can have a call next week?

(general agreement)

There will be an Async TF meeting next week - regular time, DaveO chairing.

the big picture

chair: dealing with LC issues in the next few calls

UNKNOWN_SPEAKER: perhaps close them by Berlin
... with a view of going to CR or back to second LC at Berlin
... with possible exception of issue 59
... can the Async TF estimate when they can give recommendations?

glen: Juneish

chair: recommendations at Berlin?

glen: perhaps not - need face-to-face time, perhaps

chair: if the other issues are wrapped up, perhaps the Async TF work can be pulled back into the WG proper?

anish: perhaps we can split the async work in the same way as we are considering splitting the WSDL document?

issue 41

pauld: working on the document bottom-up
... created a document called "Test Suite Specification"
... this doc won't be part of the formal delivery, but will be a Note, but will be a notification of the text cases used
... have been building test scenarios at high level. Looking to ensure we have coverage of all required items.
... some of the scenarios are "interesting"
... conforming to all the tests in this test suite does not mean full conformance
... (this is standard language in relation to W3C test suites)
... possible to be conformant even if failing some tests?
... struggling to find terminology that isn't overloaded
... really should have a test for every MUST in the spec

chair: need a coverage document to identify all of the MUSTs, plus who is required to satisfy the MUST

pauld: writing an assertions document can be valuable feedback to the spec, and could be taken to the Rec.

marsh: perhaps not, not on that timeline

anish: useful to implementors, but considerable work

marsh: small audience

pauld: good to generate the document, but not include in the Rec - we'll get feedback, either way
... we need a lot more test cases to populate the document - not in a position to write all the test cases personally.

chair: we should identify the requirements in the spec as it stands today, and all the features defined

pauld: is it a problem that the MS test cases are for the early version?

chair: no - just update them

pauld: concerned about writing WSDL 2.0 test cases
... looking for contributions of test cases

glen: will help. People in Sri Lanka will help too.

<hugo> ADJOURNED

Web Services Addressing F2F

20 Apr 2005

Attendees

Contents