Web Services Addressing Face-to-Face

28 Sep 2005


See also: IRC log


Rebecca Bergersen (IONA Technologies, Inc.)
Andreas Bjärlestam (ERICSSON)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
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.)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Katy Warr (IBM Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Abbie Barbir (Nortel Networks)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Marc Hadley (Sun Microsystems, Inc.)
David Illsley (IBM Corporation)
Amelia Lewis (TIBCO Software, Inc.)
Paul Knight (Nortel Networks)
Philippe Le Hégaret (W3C)
Nilo Mitra (ERICSSON)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Mike Vernal (Microsoft Corporation)
Steve Vinoski (IONA Technologies, Inc.)
Pete Wenzel (SeeBeyond Technology Corporation)
Mark Nottingham
David Orchard, Paul Downey, Anish Karmarkar, Vikas Deolaliker, Glen Daniels


<dorchard> scribe: dorchard

BEA proposes dinner and rides at BEAWorld's rental of Great America Park

Hitachi follows up with a stunning plan for Gordon Moore talk at ?? tomorrow night

Bob solicits Wednesday evening and weekend before. Perhaps saturday/sunday leaf viewing

also proposes kamakura

AI review

paco i61 done

umit i56 done

approve minutes sep 19th

web services i18n comment

mail of 1th sept which requests feedback.

mail of 15th sept which requests feedback

hugo: closer to xmlp or ws-desc than to ws-a.

WG takes no action

issue i61

Paco runs through his proposal.


paco: the wsaw:action attribute does not mandate ws-addressing
... if required="false" and wsaw:usingAddressing is set, the message must have the complete set of wsa header blocks.

DavidH: for example, can't have message with messageId but no action

general approval of the first paragraqph

discussion of 2nd paragraph

anish: may be ws-a binding for udp

rebecca: what does "this" refer to

paco: the latter

markn: add [core, applicable ws-addressing protocol bindings (e.g., SOAP)] after sentence fragment "senders MUST use all header blocks mandated by

<dhull> UsingAddressing present, required = true ==> MUST follow rules in core and other applicable bindings. In particular, MUST include wsa:Action

<dhull> usingAddressing present, required = false (or missing) ==> MUST follow rules in core and other applicable bindings, if *any* MAP header is present

some discussion about "which response" messages following initial messages.

<dhull> If usingAddressing is missing, no constraints on WSA

paco: what is the scope

anish: this text will go in wsdl doc, and this doc would say the requirements.

paco: meps are a natural scope, but not the only one.
... could scope be all operations in same interface?

anish: say one operation that is req/respon using ws-addressing. then get response with ws-addresssing. Should another request without ws-a to same operation be ok?
... this should be ok for wsdl:required="false"

davidh: agrees

paco: may be other scopes.
... may want to say whole portType.

umit: putting on binding is an oxymoron.

anish: even per invocation.

paco: is the change something like change "related" to any message sent within same instance of an mep.

markn: "any subsequent messages in that exchange pattern"?

davidh: suggests putting into bullets

paco: we should replace "header blocks" with something non soap specific.

scribe loses scribe ability for a bit.

paco: need a clear way to say whether properties are required

davidh: when you have message addressing properties present, then header blocks will be in the soap messages

anish: what about defaulting if ws-addressing not fully engaged, say mU="false" on partial.

paco: mU isn't part of it at all.

in either mU=" * *" or wsdl:required=" * ", it doesn't matter. Receiver will honour Addressing.

anish: if mU="false", receiver has already said that by "usingAddressing" marker, receiver will honour.

Glen make sstunning point about how many non-soap bindings we have.

davidh: we should talk about properties, not header blocks.

paco: it's binding dependent on how to determine if ws-a is present.
... this is a binary decision.

davidh: if I get this kind of soap message, the set of meps will be x...

paco/davidh get into whether ws-a enabled is binary decision or what the scope is.

would there be engaging that is different on different bindings?

<uyalcina> i would prefer somewhere in this text, esp if we were not to remove the wording about "headers", we should include language to indicate mU value is not relevant. It does not come across clearly.

davidh: this should be independent of the wsdl port type (interface) definition
... the soap and whatever binding figure out what properties are present.

glen: could say usingAddressing is specific to ws-a soap and wsdl bindings, some other binding could define it's own usingAddressing and semantics.

markn: 1 path: specific to soap, etc. 2nd path: be more generic

TonyR: IIUC, the presents of any property switches on ws-a, but does that really mean "any non defaulted property".

mark tries to gauge room's interest.

mark: maybe usingAddressing is too simplistic.

anish: need an additional flag, not only addressing is supported/required, and it is possible to have another soap binding how to indicate...

davidh: all we need to do is say explicitly if there are no soap header blocks present then no soap properties..

glen: axis2 twigs of properties that are always there in messages, even without ws-a.

tonyr: all this is putting a different face on the flag. This is pretending there's no flag.

davido: could tonyR live with "if non-defaulted WS-Addressing properties"?

mark: change to say "if [the WS-Addressing protocol binding is engaged], the use of the Message Addressing Properties MUST be..."
... more cleanup. (should he be an editor?)

tonyr: given an endpoint that takes both non-wsa and wsa, if you take an endpoint that only takes wsa then it.. (scribe lost rest)

<pauld> doesn't find it useful to discuss non-soap bindings for this issue

<TonyR> I want to separate the idea of WS-Addressing being engaged from the idea of MAPs being in the message

markn: proposes we just have to fix the text within the [] in proposed text.

<mlpeel> Sounds good

<TonyR> I was suggesting that the SOAP binding may CHOOSE to set the notional "WS Addressing is engaged" flag based on the presence of a WS Addressing SOAP header

jeffm: is this context free determination of ws-addressing engaged?

glen: if it's soap and actual header blocks are present then...

<TonyR> No - not context free - absolutely not - the decision is made by the protocol

<dhull> Paramount's Great America: http://www.pgathrills.com/

issue 56


anish: not defaulting makes sense if endpoint/o port not specified.

umit wants to remove item #4.

I can't scribe umit's comments

umit: need a motivation for which parts of EPR would need to be in endpoint

markn: paraphrasing umit, close 57 with no action then

jonathan: relationship to destination and http location is important
... also relationship between wsa:endpoint references's address and endpoint's address.
... maybe change endpoint address to be "generated endpoint address" which takes into account http:location
... or another alternative.
... endpoint ref address with endpoint address then add http location

anish: we don't need eprs to solve this..?

markn: 57 is about placing ref params in wsdl.

paco: want to be able to place ref params in wsdl.

davido: eprs in wsdl doesn't make sense because metadata is covered in other areas and ref params should be dealt with in part of wsoap:header mechanism.

anish: destination value could be common across ports and want to indicate that.
... if 10 different ports and same thing, then have single epr? (not sure if I got it)
... a wsdl 11 service element with a port, soap:address foo, another with soap:address bar.
... if we have epr, the rules are really clear.

<Gil> order of human concerns: 1) food, 2) sex, 3-487) (other stuff), 488) web services specifications

anish: wsa:destination could be different than address.

glen: wsa:to could have more dispatch.

could have wsa:to different than http location.

<uyalcina> Glen, there is nothing in the specification that allows you to do this today, so the assumption does not hold as the specs are written

anish: bullet 4 allows distinction between endpoint address and endpoint/port address.
... wsa:desination has to match the wsa:to, but not wsa:endpoint address.

<uyalcina> wouldn't that require you to use an EPR always to use WS-A?

jonathan: If you make epr and endpoint/port address orthogonal, then when you add wsa:endpoint reference then does the MAP property. This means wsdl:address isn't MAP property

anish: slightly different. Didn't mean to say completely different, was pointing out bullet #4 has a problem wr earlier discussions. Given a wsdl and wsaddressing is being used, how do you figure out destination property.
... there is also the case where creator of service creates wsdl but not epr, the value of destination is the value is the thing in the port/endpoint address. Then there is a problem when EPR is added.
... wants to delete bullet 4.

gil: need to explain when endpointreference and endpoint/port are different.

<uyalcina> it seems to me that all we wanted to avoid physical/logical destination, but this proposal requires you to define the relationship of destination and the actual WSDL endpoint address and would require you to treat destination as a more nebulus concept. Today we don't go there.

dorchard: against setting reference parameters in epr.
... against setting soap header blocks by using EPR when we already have wsdl 1.1 and wsdl 2.0 constructs for header blocks.

anish: dave, you for setting destination using wsoap:header?

markn: 1. No EPR; 2. EPR aligned w/destination. 3. EPR "loose".

rebecca: we added metadata into EPR. If EPR not going to destination does it disallow?

umit: the WSDL has all the policy/metadata stuff.

+1 to umit

markn: option 2 is keep statement 4, option 3 is remove statement 4

<pauld> scribe: pauld

Straw Poll: options for i056

option 1: No EPR (5)

option 2: EPR Aligneded w/dest (4)

option 3: EPR "Loose" (5)

objections to option 2 (daveo, hugo, glen, others)

umit: prefers option 2 to 3

chad, hi

chad, question: options for i056

chad, option 1: No EPR

chad, option 2: EPR Aligned w/dest

chad, option 3: EPR "Loose"

<anish> vote: 3

<RebeccaB> vote: 3

<TonyR> vote 3, 1

<GlenD> vote: 3, 1

<dorchard> vote: 1

<hugo> vote: 3, 1

<vikas> vote: 1

<jeffm> vote: 3

<dhull> vote: 3, 1

vote: 1

<andreas> vote: 1

<TRutt> 3

<RebeccaB> vote: umit:2,1

<TRutt> vote 3

vote: trutt: 3

<TRutt> vote: 3

chad, votes?

<Marsh> vote: 1, 2, 3

chad, trutt: abstains

chad, trutt abstains

chad, vote: trutt: abstains

<dorchard> chad, trutt: vote: 0

vote: trutt: abstains

<dorchard> trutt: vote: 0

<Paco> vote: 3, 1, 2

<anish> vote: bob: 1, 3

<prasad> vote: 1, 3

chad, options?

<TonyR> chad: votes?

chad, votes?

<anish> vote: abstain

chad, count

<chad> Question: options for i056

<chad> Option 1: No EPR (7)

<chad> Option 2: EPR Aligned w/dest (1)

<chad> Option 3: EPR "Loose" (7)

<chad> 17 voters: andreas (1) , anish () , bob (1, 3) , dhull (3, 1) , dorchard (1) , GlenD (3, 1) , hugo (3, 1) , jeffm (3) , Marsh (1, 2, 3) , Paco (3, 1, 2) , pauld (1) , prasad (1, 3) , RebeccaB (3) , trutt () , TRutt (3) , umit (2, 1) , vikas (1)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 2.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - No EPR

<anish> chad: details

<anish> chad, details

mnot: so, that covers i56 and i57, but we will still need text to cover how to infer the destination

marsh: we need to consider when address and the EPR differ

daveo: setting wsaddressing is on the binding, not on the endpoint
... how is echoing a refparam different to a fixed value in schema?

mnot: lets see if we have a use-case for describing refps in wsdl before designing it

daveo: service may provide a supplier or sessionid

marsh: routing headers could be constant, not ephemeral

paco: we have to consider WSDL 1.1 as well as WSDL 2.0

anish: you fix it in schema, not WSDL, but how do you specify a fixed value on an endpoint basis

marsh: part of my concern is it's harder to create a *structure* which may happen to have fixed values

mnot: we seem to agree there is functional requirement, it's the style where we differ
... if we allow an EPR, then we're done. it's the not allowing case where we have more work

daveo: wsdl 1.1 and 2.0 allow you to set SOAP headers. allowing EPRs introduces potential collision

mnot: straw poll revealed slight leaning to not allowing an EPR. Can people who voted 3 explain their position

anish: ERP destination may be different to the WSDL port value
... this issue is about how to figure the value of the output MEP

glen: the case where you don't specify the relationship toAddress ..]

tom: raises physical (v) logical address distinction

marsh: all addresses in WSDL are logical, though in the case where you don't have a map, dereferencing the logical is a good option

discussion of mapping between mapping between addresses or if the To address can be used as a second layer

glen: imagine a world where wsdl endpoint was the addressing endpoint, much as i like 3, 2 is my preference

<dorchard> another point would be what about combining policies of EPR and WSDL.

room moving towards 2, though virtually noone voted for it

<dorchard> hmmm.. I'm still firmly astride #1.

mnot: restates our charter requirement "providing the mechanisms for defining Web Services Addressing property values in WSDL 1.1 and WSDL 2.0 service descriptions;"

<Marsh> hmmm... I'm leaning away from #1 towards #2, just because refPs are simpler and direct.

umit: 1 is preferable - given we have metadata section in an EPR, we would need to make the WSDL and the EPR consistant which is difficult

anish: solving i56 is more interesting to me than including refps in a description

number of people interested in setting a To message addressing property not in the WSDL

<dorchard> I think it was around 5 people interested.

anish: anyone can define extensions which conflict, it's a generic problem, not specific to the EPR in WSDL proposal

marsh: what would this pseudo destination be?

mnot: cross that bridge when we get there

anish: we're defining the WSDL binding for addressing, EPRs is a big part of addressing. I could do this with extensibility, but that wouldn't be good enough

marsh: i the question wherer we EPRs in wsdl at all?

mnot: i'm exploring the functionality required
... also is this testible?

anish: i believe so

discussion of info required for test data (essentially out of band)

mnot: what about this as an optional extension?

marsh: sounds like we're talking about a broker - send it here first, then dispatch, if so is one level going to be enough

pauld: reminds me of source routing

glen: this is essentially about multiple possible destinations within a single node

marsh: this reminds me of multiple to's

anish: i have a multi-protocol use-case, multiple ports in wsdl, and i want to tell clients sending over different paths to use the same To value

discussion spirals into identity / physical address death spin

anish: we need to reexplore why we have two different things - EPRs / endpoints

umit: we can solve your problem with the machinary we already have

paco: this is why in the broker model refps are more interesting than To

mnot: interested to see if this discussion has changed people's opinions

<uyalcina> +1 to Paco

staw poll: do we need to have a separate WSDL address to Addressing property?

yes: 7

<mlpeel> I vote yes

no: 6

marsh: is our address the same as the WSDL endpoint address is the question?

glen: they should be the same thing, it's not just syntax

daveo: i don't understand the way you voted (no), glen

marsh: if the stuff coming from WSDL is different, how do i now represent that in SOAP headers, it's a new thing

mnot: wants a proposal for option 1

daveo: maybe we could make the infosets the same even though WSDL 1.1, 2.0 and EPRs serialisations differ ..
... heard glen says he wants them to be the same thing, but thinks making the serialisations the same isn't realistic

glen: so we could have an xslt to go between them

anish: asserts they aren't the same thing

<mnot> DavidO's Proposal for i056: The [destination] property is taken from the endpoint or port address -

<mnot> derived address (WSDL 2.0) or the applicable WSDL 1.1 extension (for

<mnot> SOAP it is taken from soap:address/@location).

chad, new poll

<chad> new poll

chad, options for i56

chad, question: options for i56

daveo: explores difference between setting values at the endpoint and the binding level. My supplier id use-case makes sense at the binding level ..

paco: WSDL bindings are reusable, but endpoints aren't

review of anish's proposals for i57: http://www.w3.org/2002/ws/addr/wd-issues/#i057

daveo: ws-addressing can reuse WSDL constructs in ways they weren't expecting

marsh: not sure the schema allows that

mnot: agreement that this would be a top level extension, not a sibling of usingAddressing

discussion of WSDL providing WSDL SOAP headers in the endpoint or refparams in the endpoint

daveo: volunteers to write two proposals for expressing refparams in WSDL

mnot: do we need to keep i56 open?

marsh: functionality daveo is proposing is good, however option 2 does this, which received the least votes and me it's a clear winner :-)

poll again

option 1: 7

option 2: 2

option 3: 5

mnot: whuptish (to daveo)
... your proposals are going to help here

<Gil> sound of a whip

i064 - Migration of @Action

marsh: outlines difficulty of migrating from addressing member submission to our rec in area of wsa:action


paco: this is a rec for wsdl authors?

marsh: yes, it's how to keep your actions aligned
... in many cases they'll be the same, which is fine, but it would be nice to ensure that someone dipsatching on action knows how to exhibit the same behaviour across the two specs
... if people following this advice, it will enable vendors to easily support the migration

anish: advice is don't use defaults in the submission case if the values match

paco and marsh discuss a service which sends two different action values in a single message

hugo: seems like primer material

mnot: or even a note or a document

marsh: asking for higher visibility

hugo: seems like we're highlighting bug fixes and what's changed

pauld: seems like it could help adoption by demonstraing how to migrate

marsh: communicates to current users of WSE how to plan for W3C WS-Addressing

anish: explores how this helps in migration
... wonders what' special about action, other machinary is required to process our messages beyond the member subission - we have defaults for To, etc
... still needs to understand if this really helps in migration

marsh: walks through proposal
... again

mnot: would be concerned this baloons to an entire migration guide

hugo: this is essentially my discomfort. It sees motherhood and apple pie. Wierd to pick on this and put it in the main document

marsh: but what else would you call out - have a complete table:?

discussion of what's so special about action

hugo: concerned about the word "recommend"

jeffm: we could use "suggest"

i056 again

daveo: presents his proposals for i057: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0039.html

umit: worries that having a type for refps makes them no longer opaque

daveo: the meaning of the content is still opaque

glen: potentially duplicate incompatible type definitions for a single element

paco: don't think you can do the redefine in schema

daveo: you have the same issues with refparms not matching a schema held locally
... you could use 'redefine'

paco: schema defines types, but this is about instances

daveo: wanted to express the complexity of using EPR in WSDL in option #5
... option #6 is for completeness
... option #3 is best

<mlpeel> I prefer #3

mnot: preferences between option #3 and #4?

option 3: 11

option 4: 1

dhull: you can refer to an endpoint via a static WSDL or dynamic EPR, and we seem to be striving for harminisation
... we'd like to be able to add SOAP headers into a static WSDL, there isn't much else in an EPR: address, refp, metadata

anish: there is an extensibility point

dhull: i'm pro 3^H 1

anish: if you have an EPR extension, you also need to think about expressing it in an endpoint in WSDL

rebecca: so the only thing we need to worry about are refps

glen: bangs the "why cant and endpoint be the same as an EPR" drum

andreas: explores the need to replicate the refp to SOAP header echoing

glen: surprised we only describe how to formuate a reply message, not a request

rebecca: worries that EPR in WSDL would make EPRs static

omnes: that's not a risk as the EPR can override any information in the WSDL

daveo: a design point of WSDL is the reuse of bindings, etc, but there seems to be an argument here for having them all in one place (inside the EPR metadata section)
... why would you want to flatten the WSDL model?

vikas: why are we putting dynamic information in a WSDL

glen: WSDLs can be minted on a per-customer basis

vikas: sees any content inside EPRs being dynamic

daveo: some of the constructs may not be so dynamic, you seem to be arguing against that

vikas: yes

straw poll, again

chad, new poll

<chad> new poll

<Gil> one vote per company?

<dhull> vote: tibco: 1, 3

chad, question: options for i056

option 1: no EPR

<dorchard> vote: 1

option 2: EPR Aligned

<anish> vote: 3

option 3: EPR "Loose"

<dhull> vote: tibco: 1, 3

<anish> vote: 3

<dorchard> vote: 1

<jeffm> vote: becky: 3

<TRutt> vote: 3

<Marsh> vote: option 2, option 1

chad, options

<GlenD> chad, thou art confused

<dorchard> vote: option 1

<GlenD> yes I know.

chad, option 1: no EPR

chad, option 3: EPR "Loose"

chad, options?

chad, option 2: EPR Aligned

chad, options?

<anish> vote: 3

<dorchard> vote:1

<dhull> vote: tibco: 1, 3

<mlpeel> vote: 1

<TRutt> vote: 3

<jeffm> vote:becky:3

<Marsh> vote: 2, 1

<TonyR> vote: abstain

<uyalcina> vote: 2, 1

<GlenD> vote: 1

<vikas> vote: 1

<Paco> vote: 1

<hugo> vote: 3,1

<andreas> vote: 1

<yinleng> vote:3,1

vote: 2, 1

<vikas> bob: 1

vote: bob: 1

chad, count

<chad> Question: options for i056

<chad> Option 1: no EPR (8)

<chad> Option 2: EPR Aligned (3)

<chad> Option 3: EPR "Loose" (5)

<chad> 17 voters: andreas (1) , anish (3) , becky (3) , bob (1) , dorchard (1) , GlenD (1) , hugo (3, 1) , Marsh (2, 1) , mlpeel (1) , Paco (1) , pauld (2, 1) , tibco (1, 3) , TonyR () , TRutt (3) , uyalcina (2, 1) , vikas (1) , yinleng (3, 1)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 2.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - no EPR

chad, details

anish: unhappy at this decision, not reflecting all the EPR in the WSDL could be short sighted
... 2 is my prefence, 3 i could live with

who would lie down in the road for 2?


who would lie down in the road for 3?


rebecca: also unhappy with 1

discussion of how near the middle of the road those thinking about lying down are

glen: explores anish's concerns about pulling an EPR apart

anish: i may have an extension in a MAP, e.g. the contents of an EPR could change the behaviour of an MAP. I could also add new MAPs

hugo: understand why you perfer 2, but the issue for i56 could be resolved by 1 and 3?

marsh: I started thinking like anish, which is why i preferred 2 over 1. Once you consider extensions of extensions, 1 flattens that problem - it's either an extension of WSDL or extension of an EPR

<GlenD> there may be some extensions which only make sense at runtime and don't at design time

marsh: unlikely to get automatic behaviour here, you're going to have to say something about how an extension may work

rebecca: argues for using EPRs as a template

umit: 1 and 2 aren't identical to each other

glen: just in resepct to the destination address

umit: use-case for 3 can be handled by extensibility

mnot: we seem to be heading towards a formal vote

is 2 a point of consensus, who can't live with 2?

glen: i'd object to 2
... i can't have a generic EPR processor without specific code for when EPR info occurs in WSDL


<anish> anish: the processing of EPR wrt to populating the MAPs is unchanged as to whether the EPR occurs in WSDL or somewhere else

dhull: what is the motivation for 3, how do you deal with conflicts?

<anish> anish: EPR does not specify all the MAPs but it does specify [destination] and [ref params] and possible extensions to MAPs

<anish> anish: the only thing that you have to do wrt to extra stuff when the EPR is in WSDL is -- check that the port address and wsa:Address is the same (if both occur)

rebecca: cites multiple protocols to a single endpoint

dhull: how do i interpret the multiple ports

rebecca: if you don't understand the options, ignore them

<anish> i'm begining to like davido's option #6 :-)

dhull: implementing multiple ports in the metadata seems almost to work by accident as opposed to explicitly expressing multiple endpoints

discussion heads off into the woods

paco: recursive metadata ...

marsh: as a leading proponent of #2 i'm willing to drop it to get a binary vote

paco: WSDL inside metadata inside an EPR inside WSDL is something we should rule out

marsh: expect comments on this, we should explain why we say nothing

glen: doesn't like 2 architecturaly

<uyalcina> +1 to Glen

paco: can live with 2 if we rule out recursion

glen: don't repeat yourself principle serves us well

anish: then vote for 3!

mnot revises option 2 on the board to specify "Semantics of WSDL-related metadata (...) are undefined in such EPRs"

andreas: 2 and 3 seem very complex with caveats which many people will have to understand

dhull: 1 and 2 don't seem antithetical

<uyalcina> i agree with andreas. It is too complicated that we can not seem to agree in this room even what these options would mean.

anish: having the same EPR in multiple places allows another spec to define how to compare them. splitting them up precludes that

marsh: is option 3 still on the table?

hugo: i may object to either 1 or 2
... we don't prevent people distinguishing between physical and logical address, but 1 and 2 could do this

s/Formal Vote//

mnot: does anyone object to accepting option 2?

yes, 3

<mnot> i056+i057

<mnot> option 1:

<mnot> The [destination] property is taken from the endpoint or port address -

<mnot> derived address (WSDL 2.0) or the applicable WSDL 1.1 extension (for

<mnot> SOAP it is taken from soap:address/@location). wsa:ReferenceParameters can be a child element of a wsdl20 endpoint or a wsdl 11 port.

<mnot> option 2:

<mnot> a) Allow a wsa:EndpointReference element to be included as a child of

<mnot> wsdl20:endpoint or wsdl11:port.

<mnot> b) When a wsa:EndpointReference element is present as a child of a

<mnot> wsdl20:endpoint/wsdl11:port the usual WS-Addressing/binding rules apply

<mnot> [destination]=wsa:EndpointReference/wsa:Address. Semantics of WSDL-related metadata (e.g., WSDL namespace metadata, wsdl-related MAPs) are undefined in such EPRs.

<mnot> c) When there is no wsa:EndpointReference child element, the

<mnot> [destination] property is taken from the endpoint or port address -

<mnot> endpoint/@address (WSDL 2.0) or the applicable WSDL 1.1 extension (for

<yinleng> abstain

<mnot> SOAP it is taken from soap:address/@location).

<mnot> d) If there is both a wsa:EndpointReference and an endpoint/port address

<mnot> then they must have the same value.

<mnot> option 3:

<mnot> option 2 - d

Formal Vote: Accept Option 2 for i056 and i057


BT - Y

CA -abs

Ericsson - N

Fujitsu - N

Hitachi - N

HP - abs



Microsoft - abs

Novell - N

Oracle - Y

SAP - abs

Sonic - N, SONOA - N

Tibco - N

W3C - N

WebMethods - abs

No 9, Yes 4, Abstain 5

Formal Vote:Option 1 or 3 for i056 and i057

BEA - 1

BT - 1

CA - abs

Ericsson - 1

Fujitsu - 3

Hitachi - 1

HP - abs

IBM -1

IONA - 3

Microsoft - 1

Novell - 1

Oracle - 3

SAP - 1

Sonic - 1



W3C - 3

WebMethods - 1

Option 1 - 12, Option 3 - 4, abstain - 2

any objections to adopting option 1 for i56 and i57

anish: i don't know

RESOLUTION: i56 and i57 closed by adopting option 1

i064 - reprise


anish: there seems to be other issues for migration, eg defaulting of other MAPs including To
... this addresses a particular issue Microsoft has, but there may be other issues we should address in this area

marsh: then raise them as separate issues

pauld: mirrors our experience in migration

marsh: for me it's orthogonal if there are other migration issues, this is something I'd like to see adopted, but it doesn't preclude other migration issues being added

anish: maybe a separate migration note, or Primer would be better, but then this in a separate section would be OK if we can add other issues

hugo: would like to see the other migration issues before deciding where it should all go

<anish> i'm not suggesting a separate note or primer

marsh: doesn't want to tie this to a bigger boat that might not float

pauld: one other area which will trip people up is the loss of refprops
... but explaining the reasons behind *why* we made descisions isn't usual in specifications

anish: would accept this if it was a part of a list of each change made, possibly with one or two minor changes

hugo: the targetNamespace urn seems more like a bug than a means of migration

<scribe> ACTION: Jonathan to formulate a proposal for a migration guide [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action01]

mnot: wrap up

<anish> Scribe: anish

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0033.html

issue i059

<GlenD> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jul/0010.html

Mark: what do we need in our docs to close our issue and go to LC. That is the important thing.

Glen: after months of sporadic discussion in ATF, we came up with guiding questions to frame the landscape.
... the basic idea is that for addressing to succeed, a lot of things that people want to do should be in our test suite
... for example async req-res over http
... What do we need to do in various WS WGs to specify in clear way as to how this works without any handwaving
... The 1st issue being: what about one-way. SOAP does not have one-way.
... We asked the one-way the XMLP WG is going to work on one-way MEP in SOAP
... But there is a question of is that what we want, how long that is going to take?
... There is also the WSDL question wrt one-way.

Mark: we can specify something in our WSDL binding without referring to the one-way MEP

Glen: we could

Mark: and we could specify thing in our test suite, which is not a REC

Glen: the case of req-res with wsa:ReplyTo over HTTP with multiple connection is not supported by any specs right now
... our charter says that we have to do all MEPs in an async way

Paco: we don't have a way to represent this in WSDL

Paul: we go to REC and move forward with SOAP spec instead of WSDL

Glen: we need to talk about whether some of the issues with async are our issues
... here is one option: when u use wsa:UsingAddressing that means async and we don't need to do anything else. But the problems is that we have been doing this for a while and this isn't written down anywhere

Paco: the issue is you have to do this in a way that does not contradict the binding

anish: reminder to the WG that they need requirements for us, so that they can craft their charter correctly
... if we don't they will go ahead and create a solution that they think is right

paco: q-
... we can agree on the runtime behavior first and then we can figure out how these things are speced out

Glen: we have a meeting in the bay area which turned out a number of pictures with how things look on the wire
... for one-way, req-res using addressing
... it was 4 way matrix, with one-way protocol, two-way protocol and one-way MEP and req-res MEP
... there is a general question about relationship between WSDL MEP/SOAP MEP/Transport MEPs

Umit: in the sunnyvale meeting, there was agreement on the wire level agreement, but it did not go beyond udp/http layer. The problem is to figure out whether we are going to try and solve the problem only for http or in a general way

Arun walks in the room

Glen: the relationship between soap and wsdl meps is the core question
... in some proposal there are SOAP meps, some proposal don't
... there are three choices:
... one-to-one mapping between SOAP and WSDL MEP, transport stuff happens below this
... the 2nd approach is soap mep are tightly coupled to transport MEPs. Eg, soap req-res binds to HTTP req-res. At the WSDL level it is not tightly coupled.

umit: the xmlp wg cannot solve this problem

glen: xmlp has requested requirements from us
... when someone picks up our specs and wsdl/soap spec they should be able to build something that will work

<pauld> whiteboard diagrams from Palo Alto: http://www.flickr.com/photos/psd/9876773, documented by daveo here: http://www.pacificspirit.com/Authoring/async/async-scenarios.html

Mark: we need to not focus on the solution here (for the things that will be done by XMLP). we need to focus on requirements

Glen: that depends on the solution that we pursue here in wsa

paco: i agree that we need to figure out our needs. it is not our job to figure out the direction. that is for wsdl and xmlp to figure out

Glen: i don't agree

paco: how wsdl meps map to soap meps is not our job

<uyalcina> +1 to Paco

daveo: i don't think anything that there is anything that glen said that contradicts that

paco: glen is mixing requirements with solution

glen: can we do that cleaning without going into solution space

daveo: we have to say what happens in the case where there is a non-anon replyTo address

glen: in that case u would say something like what comes back on the HTTP response as long as the "response" is sent back to replyTo

daveh: we need to provide feedback from ATF to XMLP
... the wsa spec does talk about what anon means and how much we say about HTTP and anon
... but that is influenced by the async model
... it would be nice if some other layer was providing a crisp definition that we could point to
... I would like to call attention to DH2 proposal in Glen's email
... DH2 is something that is not in Glen's email but rather something that i have been working on

jeff: this is not a unsolved problem
... this is not that hard problem to solve
... at the application level, how in wsdl we specify async
... i just think we could be done by that, maybe we need a one-way mep

umit: what i feel is that, we have the wire level stuff, we have to make a decision in the test suite anyway. In the case soap 1.1, we just need a marker, there is a proposal for that. We can claim victory with that and not solve the whole problem.

daveo: right, effectively we would be creating our own soap binding anyway

umit: we have to build a test suite which we have to implement anyway

<pauld> +1 to umit

mark: our charter says that we need to use WSDL meps in async way, nothing about SOAP
... can we define a WSDL extension and get this done
... there are also things which are out of scope in the charter

daveh: i agree that this is not new, the difficulty we had was how to map that to wsdl and soap. That is the hard part and we are feeding into xmlp to make the description easy.
... easy things should be easy and hard things should be possible

Glen: i'm very amenable to Paco's view that we look at this top-down in a direct way
... unfortunately, that isn't as easy
... I'm very sympathetic to what Umit just say -- get this done with a minimal thing
... I would in general IMO we should make minimal changes. If xmlp and WSDL do what they do to make this easier in the future.
... creating new soap binding right now, if that can be avoided, would be good
... If things change drastically, then we can deal with it later

Mark: i heard some folks say is: do we push things down to SOAP or do it in WSDL
... eg have extension that changes the meaning of bindings
... Paco reminded us that we need to do this not only for SOAP 1.2/wsdl2.0 but also WSDL 1.1/soap 1.1
... we can't change those spec
... in that case, pushing things into wsdl extension for wsdl 1.1 is the only solution
... the question is: do we want to take the same approach in wsdl 2.0 or do something different

daveo: the timing for what xmlp may come up with it, if we go to REC and then xmlp does things differently, then we can do a backward compatible ws-addressing new version

anish: there is a proposal to do exactly that





mark: the asyntf went on for > 6 months, we are not terribly closer

glen: we have framed things, but there isn't consensus
... getting wsa to work dips into architecture

mark: we should give xmlp feedback about their binding

glen: what do we say about this in wsdl (about wsdl out message and the soap binding)
... a simple two step process would be to errata to soap 1.2, and then make sure that WSDL allows one to say where the in/out messages go, perhaps with extensions

anish: so we can define extensions that modify/change existing binding if we have to

glen: that is what marc's proposal is, we need to perhaps tweak this

<mnot> http://www.w3.org/mid/1EFFF9BA-6069-4EFC-AEE3-EB4AD09770B2@Sun.COM

glen: everybody agreed in the TF that there should be markup in wsdl (optional) which says which bindings are acceptable on the response message

daveo: the problems that i have with marc's proposal is that u can't take a binding that has constraints on it and say that they don't apply. This needs to be a different binding.

mark: we need to figure out that we need such a binding, irrespective of whether this is a new binding or not

umit: agree with daveo

mark: what marc is saying is that xmlp will do this, we won't do this.

glen: is it ok to add things to a binding. That is what extensions are for in WSDL

anish: issues around mixed transport protocols for wsdl 1.1

glen: not a problem we just specify the right extension

paco: lets solve the simple wsdl1.1/soap1.1 case, lets do that and figure out what the requirements are

mark: can we figure out the async bit and soap bit for one-way. From my perspective, i would like to see a proposal for this along with the enabling bits that are required

umit: we sent a proposal to the async tf (paco, anish and i)

mark: it would be helpful to have a person/people go off and figure out what the wsdl extensions would look like and what requirements it places on soap etc
... if people could go away for a week or two and come back

glen: this is going the route that Paco was suggesting -- lets do the soap11/wsdl11 now and figure out how that would look like

<scribe> ACTION: proposal to address the issue of how to solve issue i059 for wsdl11/soap11 and figure out how the WSDL extension would look like [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action02]

mark: xmlp has asked us for requirements not design advice
... can we give them anything at this point

glen: no, not yet
... it depends on the middle layer
... depending on how we do this, all we may need is a one-way mep
... but another way is to say that we need less from you

mark: but xmlp is going to do one-way, so it would suffice for us

gil: we can't give them all the requirement, but that would be one of them

mark: well we can say that one-way is all we need

glen: we may want them to fix their existing binding

mark: so do we agree that all we need is (a) a one way mep and (b) errata to existing soap binding

<Zakim> GlenD, you wanted to quickly point out something re extensibility and naming

daveh: suppose we get a one-way binding from xmlp, what does that mean? Now any async req/res can be built on top of that one-way?

Glen: my view is that what we need is the ability in wsdl to describe as to what/how to replyTo
... HTTP is natively a transport level req-res
... if we allow 202
... then we can use that to do async
... wsdl 2.0 does not say explicitly to take the input message in wsdl and stick it in the soap request message and so on
... so that is where the glue comes in

daveh: there is more than that

glen: yes, but that is the 1st step
... then comes the extension

daveh: i don't see that as a wsa extension

glen: who else?
... we need the hook in wsdl to hang our hat on

daveh: where is the state machine

glen: in the extension spec

daveh: sounds suboptimal. Hence the proposal that I sent out (DH2)

daveh describes his proposal

daveh: to completely handle what is going on in async req/res, the wsa extension to wsdl will be non-trivial and it is as much work as my proposal

mark: i asked folks to send their proposal to the list and only one person sent his proposal and he is not here

daveh: i did sent one too, but i did it today. The other proposals are not secret either

mark: i'm looking at this from the POV of what does it take to declare victory
... how does your proposal get us there?

daveh: afaics marc's proposal says we need a 202 response. we agreed on to allow a binding to say that it will accept only certain transports.
... the thing about 202 ack doesn't related to WSA
... WSA could probably declare victory right now

mark: we could do this in testing?

daveh: not clear

mark: but u are saying that we don't need to add any text to our spec
... at a very high level the proposal we have is come up with a addressing extension to wsdl 1.1 and see how that looks

daveh: there are lot of things in here that people assume. there is no distributed state machine that is defined
... there is no analogous dist. state machine that talks about the requester, responder, fault endpoint and reply endpoint
... OTOH, this is not a WSA issue
... I'm torn here. I'm not proposing anything that is core WSA, but it needs to be solved.

mark: we haven't had anyone dispute the action item that was assigned.
... are any of the proposal radically different from the previous discussion
... that can't be brought up as issues against the outcome of the AI

daveh: we have a case of blind men and the elephant
... the proposals are not necessarily mutually exclusive
... here is my quick summary of my DH2 proposal --
... this builds on my previous email to the async tf
... the idea is to try to factor out the state machine from what kind of message gets transported and how it gets transport

<Arun> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0045.html

daveh: req-res is req-res regarless of how things get sent
... a message goes from sender to receiver. Both have 3 states: request, success, fail
... it defines a application level state machine
... wsdl in-out is modelled as an incoming request mapped to a outgoing reply or a fault
... you have 6 little state machines going around
... if you take this formation and what it means, it maps to existing req-res but makes it more general
... at the soap level this is equivalent to what we have
... but brings the generalization to the soap level
... at the soap level there is a bunch of one-way exchanges
... since HTTP has two different ways we need to talk about bindings
... u have soap over post, soap over get and soap over HTTP response
... It allows u to do async req-res over http, it allows u to have the cell-phone case

Glen: there are lot of pieces of state machine to get things working. But how do u connect the wsdl mep to all the things that you are talking about

daveh: all the soap bindings are one-way pieces
... if u have wsa engaged to fomulate things in terms of one-way

mark: as a chair i'm concerned as this is ambitious
... we tried to do this in XMLP and it took a very long time
... i'm not sure we need that level of detail to declare success

daveh: this is something that made things conceptually easier for me

mark: i don't want to stumble over too many layers of abstraction

daveh: only two layers of abstraction

glen: my proposal is in line with marc's
... the important part is to define the glue between wsdl mep to soap mep

<dorchard> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/att-0159/WS-Addressing-SOAP-Adjuncts.html

daveo: the 1st proposal at the URL is talking soap req-res MEP in soap and making it one-way
... calls it the soap-request MEP
... it is a one-way MEP, it follows the soap binding framework
... it then has a http binding for that
... it does a little bit of change to the existing binding
... it is mostly cut-paste-prune
... one of the problems is: what if we decide that for description purposes, how is the mapping from WSDL MEP to SOAP MEP
... this allows you to map a WSDL MEP to multiple SOAP MEP

<dorchard> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/att-0008/WS-Addressing-SOAP-Adjuncts.html

Dave's email with 3 proposals is at: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0046.html

mark: so the wsdl would point to soap req-res, but a new extension will say that it is now two soap one-way

daveo: yes
... the next proposal has one-to-one mapping of wsdl and soap MEPs
... we still have a one-way MEP
... but we have a complicated soap binding that takes a SOAP req-res and has a property that says whether or not you have a separate HTTP connection
... it take a variety of SOAP MEP it does a variety of things.
... There is an algorithm in the spec that defines this
... it does 2 things: allows one-way and allows nesting of http binding
... there is a comment about why i don't like the state machine
... it is fairly complicated, but one binding supports one-way and req-res with multiple http connections

Mark: which one do you prefer between the 3 proposals

david: #3

<dorchard> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html

davido: the 3rd proposal removes the notion of soap-ness
... there is a request and there is a response
... response happens after the request
... there are uris for request and the response
... the binding says how the request and response gets sent/received
... the ws-addressing http binding specifies how messages are composed
... I favor this approach. I don't believe that having SOAP MEPs have helped us, in fact they have hurt us
... saying one-way or req-res doesn't help as wsa:ReplyTo changes everything

mark: you 1st proposal aligns with the previous discussion/action
... in terms of wsdl desc what is the change in the three proposals?

daveo: in the UsingAddressing we can say that we are using the request-optional-response
... it is easier for us to write the UsingAddressing, as there are fewer things to look at (specs)

mark: at a high level we are not diverting from our previous approach that we decided. the question is what kind of soap meps there are and we need to figure those things out.

daveo: xmlp is looking for direction from us and would do what we recommend. They are amenable.

umit: this isn't one person or two person's thought, there has been lot of discussion on this
... don't personalize the ideas

mark: can we come to an agreement on the proposal that we have seen and recommend something to XMLP
... I'm going to tell them that we need something very quickly that won't blow away our schedule
... if people want to go to XMLP and advocate a particular proposal they should join XMLP




<vikas> start of afternoon session

mnot: What if anything we can recommend to XMLP; if we cannot, we communicate no requirements from us to XMLP

mnot: However, then we have to live with what they do ; so lets us arrive at requirements

mnot: There are four proposals. Dave's proposal is #1

paco: All we say right now is give us a 1-way MEP

mnot: MarcH's proposal is #2

mnot: #3 and #4, Dorcard's 2nd and 3rd proposal

glen: refers to a another proposal, anish points out that it is only for soap and wsdl 11

mnot: Do we need a 5th option?

mnot: less is more

<vikas> glen and anish are in discussion about 202 "fix"

mnot: 1) 1-way SOAP MEP w/HTTP Binding

mnot: 2) Rix Req/Res SOAP HTTP Binding 202 Problem

mnot: 3) Dynamic MEP Switching or 1+2 in one binding

mnot: 4) Req/Res MEP and HTTP Binding

glen: objects to option 3) being classified as 1 + 2

dorchard: clarifies

glen: maintains position, they are different i.e. proposal 3 is not 1+2

mnot: is this a discussion that can be taken offline

umit: What is difference between 2 and 4

glen: no state machine in 4

glen: we can specify wire level messages and say we don't care how to do it

mnot: Can you live with characterization of four options

dorchard: Clarfications spends time which can be used in arriving at recommendations

mnot: adds a fifth proposal 1 + 2 (separate bindings)

<vikas> it is 2:00PM

mnot: Polls for consensus on 5 options

dhull: where is mine ? Everything is 1-way

mnot: 1-way MEP that has no directionality

dhull: yes

mnot: Isn't that #1?

mnot: Adding a sixth option: (6) 1-WAY (Directionless) SOAP MEP + SOAP over POST and SOAP over RESPONSE

anish: What do you mean by Dynamic ?

dorchard: Dynamic MEP Switching

paco: Recommend the solution (behavior) not design the solution

glen: We need to know the semantics of WSDL extension

paco: AI from XMLP was to define the behavior.

mnot: Polling for consensus again

markg: What is status quo?

mnot: Option 1

chad: new vote

<chad> new poll

chad: question: Recommendations to XMLP
... option 1: 1-way SOAP MEP w/HTTP Binding(s) [status quo]
... option 2: Fix Req/Res SOAP HTTP binding 202 problem
... option 3: 1 + 2 in one binding (dynamic MEP switching)
... option 4: Req/Res MEP + HTTP Binding (Simplified - no state machine)

chad option 5: 1 +2 (separate bindings)

chad: option 5: 1 +2 (separate bindings)

dhull: wants to reword option number 6

mnot: Recommend XMLP that whatever the solution, the ack problem should be fixed

chad: option 6: 1-way (directionless) SOAP MEP + SOAP-over-POST/Response Bindings
... options

<dorchard> Of the options: 1) is daveO #1; #2) is MarcH; 3) is daveO #2; 4) is DaveO #3; #5) is synthetic; #6; is DaveH's

<GlenD> vote: 2

<dorchard> vote: 4

vote: 1

<hugo> vote: 5, 1, 2

<uyalcina> vote: 5, 2, 1

<Arun> 2

<Arun> vote: 2

<TonyR> vote:3, 4, 1

<Paco> vote: 1

<Marsh> vote: 1

<dhull> vote: tibco: 6,5,4

<MSEder> vote: 1

<Marsh> vote: Rebecca: 5, 1, 4

<pauld> vote: 1

<gil> vote: 4

<prasad> vote: 1, 3

<Marsh> vote: Prasad: 1, 3

vote: prasad: 1 3
... prasad:
... prasad: abstain

<bob> vote 1

<bob> chad: vote: 1

<pauld> vote: 4

<mnot> chad, votes?

<dhull> vote: abstain

vote: 5, 3, 1, 2 4
... 5 3 1 2 4

<gil> gil: abstain

<gil> chad: abstain

<uyalcina> vote: 2, 5, 1

vote: 5, 3, 1, 2, 4

chad: votes

<dhull> chad: vote: abstain

<bob> chad: 1

<TRutt> vote: 1

<pauld> vote: vote: abstain

<TRutt> vote: abstain

chad: count

chad, count

<chad> Question: Recommendations to XMLP

<chad> Option 1: 1-way SOAP MEP w/HTTP Binding(s) [status quo] (6)

<chad> Option 2: Fix Req/Res SOAP HTTP binding 202 problem (3)

<chad> Option 3: 1 + 2 in one binding (dynamic MEP switching) (1)

<chad> Option 4: Req/Res MEP + HTTP Binding (Simplified - no state machine) (2)

<chad> Option 5: 1 +2 (separate bindings) (3)

<chad> Option 6: 1-way (directionless) SOAP MEP + SOAP-over-POST/Response Bindings (1)

<chad> 21 voters: anish (5, 3, 1, 2, 4) , Arun (2) , bob (1) , dhull () , dorchard (4) , gil () , GlenD (2) , hugo (5, 1, 2) , Marsh (1) , MSEder (1) , Paco (1) , pauld (4) , Prasad (1, 3) , prasad () , Rebecca (5, 1, 4) , tibco (6, 5, 4) , TonyR (3, 4, 1) , TRutt () , uyalcina (2, 5, 1) , vikas (1) , vote ()

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Tie when choosing candidate to eliminate.

<chad> Tie at round 1 between 3, 6.

<chad> Tie broken randomly.

<chad> Eliminating candidate 3.

<chad> Round 3: Eliminating candidate 6.

<chad> Round 4: Tie when choosing candidate to eliminate.

<chad> Tie at round 3 between 2, 4.

<chad> Tie at round 2 between 2, 4.

<chad> Candidate 4 has the fewest votes at round 1.

<chad> Eliminating candidate 4.

<chad> Round 5: Eliminating candidate 2.

<chad> Round 6: Eliminating candidate 5.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - 1-way SOAP MEP w/HTTP Binding(s) [status quo]

chad, details

<TonyR> vote: 3, 4, 5, 1

<bob> chad: 5,1

<uyalcina> vote: 5

chad, count

<chad> Question: Recommendations to XMLP

<chad> Option 1: 1-way SOAP MEP w/HTTP Binding(s) [status quo] (5)

<chad> Option 2: Fix Req/Res SOAP HTTP binding 202 problem (2)

<chad> Option 3: 1 + 2 in one binding (dynamic MEP switching) (1)

<chad> Option 4: Req/Res MEP + HTTP Binding (Simplified - no state machine) (2)

<chad> Option 5: 1 +2 (separate bindings) (5)

<chad> Option 6: 1-way (directionless) SOAP MEP + SOAP-over-POST/Response Bindings (1)

<chad> 21 voters: anish (5, 3, 1, 2, 4) , Arun (2) , bob (5, 1) , dhull () , dorchard (4) , gil () , GlenD (2) , hugo (5, 1, 2) , Marsh (1) , MSEder (1) , Paco (1) , pauld (4) , Prasad (1, 3) , prasad () , Rebecca (5, 1, 4) , tibco (6, 5, 4) , TonyR (3, 4, 5, 1) , TRutt () , uyalcina (5) , vikas (1) , vote ()

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Tie when choosing candidate to eliminate.

<chad> Tie at round 1 between 3, 6.

<chad> Tie broken randomly.

<chad> Eliminating candidate 6.

<chad> Round 3: Eliminating candidate 3.

<chad> Round 4: Eliminating candidate 2.

<chad> Round 5: Eliminating candidate 4.

<chad> Round 6: Eliminating candidate 1.

<chad> Election over. Candidate 5 is elected.

<chad> Winner is option 5 - 1 +2 (separate bindings)

chad, details

chad: votes

mnot: Requirement for a 1 way MEP with anish's identified problem; no strong inclination to any particular style of solution

mnot: The WSA Group requests the XML protocol working group to fulfil the following requirements:

<pauld> I make the point that the issue for our schedule is that the 202 errata allows to to CR test the SOAP binding, the rest can wait until we have to consider describing exchanges in WSDL

mnot: Delivery of a one way SOAP MEP and corresponding HTTP binding, such as that proposed by dorchard and

<vikas> required by the WSD WG

<vikas> Correction of the ack problem pointed out by Anish

<vikas> and Timely delivery

mnot: Does anyone object to this statement

<vikas> no objections raised

<vikas> On i59, a separate group to work offline and make a proposal to wider WG

Editorial: Notational Conventions

<mnot> http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E8208172@RED-MSG-10.redmond.corp.microsoft.com

<vikas> Moving on CR Issue with no number

jmarsh: Not completely editorial but changes in wording will capture intent better

jmarsh: Discuss proposal

mnot: close it by accepting proposal


hugo: We had decided to decide on this issue much later


<vikas> http://www.w3.org/2002/ws/addr/cr-issues/#cr3

jmarsh: The existing resolution got a push back from Nokia. They want a xml:id added to wsa:epr/metadata and/or wsa:/epr/refp

jmarsh: why not wsu:id?

jmarsh: because the id is required for signing, xml:id might confuse people

<vikas> It is 3:00PM

jmarsh: if we don't have to put something in, don't

anish: Profile might dictate which xx:id to use

hugo: Can we find a compromise? We don't add it to our schema but point to other specification.

jmarsh: Nokia claims that it is a interoperability problem, but it is difficult to see why

mnot: He might be using us as a forcing function to get something else

anish: Why is this a specific problem for us ? There are lots of recomendations that define SOAP headers. But they don't say anything about ID. So why should we?

mnot: show of hands for maintaining status quo

bobf: Rule it out of scope

tony: Put both xml:id and wsu:id as alternate soultions.

<vikas> ****************** BREAK *********************** WILL RETURN AT 3:30pm

<vikas> RESUMING

WSDL LC issue LC301

jmarsh: Reading an email to public email in http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0000.html

gil: Can one get a SOAPAction back on response

hugo: In SOAP12 you can expect it

anish: wsa:Action and soap:Action could be sibling attributes and both can be specified and our spec will restrict what those values are i.e. they are the same

becky: We are putting action attribute at the message level and the WSDL group wants confirmation?

anish: They have a new attribute at the message level and we have a restriction on that attribute and we would need to respecify it.

becky: They are not asking anything that we don't want to do

anish: We need to add further clarification

umit: We may not need to change anything

anish: may be an issue needs to be raised on the consequences of this on wsdl 11

mnot: Go ahead and file it

mnot: WG agrees with that issue and jmarsh to coordinate it back with wsdl wg

CR Issue: Anonymous Address Utility

umit: Loosening definition to include EPRs from other specifications. The issue is in http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0035.html

anish: Change the semantics to say "The anonymous URI references back channel for any binding"

glen: Two changes: "Replace ReplyTo or Faulto with "an"

glen: Add "for response messages" at the end of sentence beginning with "Any underlying protoco..."

RESOLUTION: Change to: "When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as the address of an EPR, such as the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP request-response message exchange pattern provides such a channel for response messages. For instance, the SOAP 1.2 HTTP binding [SOAP 1.2 Part 2: Adjuncts] puts the reply message in the HTTP response."

CR Issue: Generating non-reply messages

<vikas> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0051.html

glen: It is mostly editorial;

andreas: From discussions yesterday we don't have an EPR in WSDL.

glen: Yes that is a different issue

mnot: Proposal accepted.

CR Issue: wsa:InvalidAddress: redundancy and wsa:ProblemIRI error

mnot: http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0004.html

<vikas> It is 4:00PM

mnot: We will push this one to next time. Everybody to read spec and evaluate hugo's proposal

CR Issue: Mapping of headers to MAPs and "WSA is engaged"

<vikas> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0038.html

dhull: How to tell is WSA is engaged when wsdl:required is false

dhull: Two options as listed

<mnot> ack dhull, paco, anish

tony: Binding decides whether wsa is in use.

<gil> +1 to jeff

jeff, there is a explicit indicator in case of soap binding -- wsa:Action

<Paco> +1

<uyalcina> I agree with Jeff that defaulting is getting in the way for deterministicly deciding just by looking at the wire whether WS-A is engaged or not.

dhull: discusses the two resolutions in the email referenced above.

dhull: larger issues is need to define it explicitly ; currently it is all implicit

tony: once you go through the binding, all defaults are set. You have to make decision if wsa is engaged before settings defaults

tony: after the default setting stage, one has list of MAPS , binding should make that decision, that decision does may not be based on content of the message.

paco: until one knows if wsa is engaged, no point in talking about maps

paco: Action is giving us everything we need. There is no need for wsa:engaged

<vikas> this discussion is in context of wsdl:required is false

anish: this is binding specific problem

anish: what is the intention of the sender of the message. If there is any header then the sender intended use of wsa

paco: we want to make explicit what the intention of the sender is, not try to guess. Action is the way

jmarsh: if action is missing, send back the header and ask for action

tony: if action is the flag, where is it determined and how it is carried forth

anish: if the receiving server understands the headers and finds no action, then?

dhull: convinced by tony's proposal

<uyalcina> I don't need to speak, I agree with Jonathan and Paco. It is simple, deterministic

dhull: Would like to propose adoption of proposal 2 in the email referenced

tony: Binding determines if wsa is engaged and everything comes after that

<vikas> This flag would be in the core and binding would implement it

mnot: couple of sentences in the core which says there is a concept of boolean flag which says wsa is engaged and that is implemented in the binding

tony: We cannot base the core on presence of headers in the binding

I've an algorithm that tells you when it is engaged:


if (mU='1' on any WSA header) //receiver must engage WSA or fault


if (receiver does not understand WSA)


fault and stop processing the message


if (any WSA rule is violated) //including missing wsa:Action


fault and stop processing the message


process the message as a WSA message


else //sender does not mandate WSA, receiver gets to choose


if (receiver wants to process the message with WSA engaged)


if (any WSA rule is violated) //including missing wsa:Action


fault and stop processing the message


process the message as a WSA message




ignore all WSA headers, if any

process the message as a non-WSA message



+1 to paul

paul: Binding dependent, ws-addressing engaged is

mnot: The whole issue boils down to if we need a concept of "being engaged" in core

mnot: straw poll says people prefer it stay in binding only and not in the core


<vikas> discussion between anish, glen, jmarsh on mustunderstand's relevance to determining wsa engaged or not

<vikas> straw poll 9 to 4

<vikas> in favor of action over "any header"

<vikas> in wsdl binding , we will say addressing is engage when you receive a message that has wsa:action header

mnot: When the UsingAddressing extension is present in WSDL, the binding (WSDL + SOAP) is engaged when a receiver processes a message containing a wsa:Action header

umit: using multiple wsdls as a case for "any headers" case is out of scope

<vikas> discussion between glen, paco, jmarsh on "usingaddressing" means wsdl binding or soap binding

<vikas> Add to SOAP Binding Document: "This SOAP binding is engaged when a receiver processes a message containing a wsa:Action header.

<vikas> Change text to: If a receiver processes a message containing a wsa:Action header, this SOAP binding is engaged

<vikas> 8 YES, 1 NO, 8 Abstains on vote to accept the text listed above

RESOLUTION: issue closed by adding to the SOAP Binding: "If a receiver processes a message containing a wsa:Action header, this SOAP binding is engaged, [and the rules of this spec are in force]."

<GlenD> Scribe: Glen Daniels


(Mark summarizes current state of affairs)

(reminder - i061 is UsingAddressing when wsdl:required is false issue)

Hugo: Why did we say it MAY use the values specified if action specified instead of SHOULD?

Glen: If it's "only informational" why should it be SHOULD?

Hugo: They haven't told you they're using addressing, and you want to try your luck and use action... unless you have info from another souce, the logical thing to do would be to use the action value specified in the WSDL.

DaveH: Where do we say that we have to use action if UsingAddressing is there?

(group editorial work)

Anish: Weren't we trying to say that if WSA is engaged (even without UsingAddressing) you have to follow the rules of wsaw:Action?

Jonathan: I'd still like to propose that our wsaw:UsingAddressing should be specific to our SOAP binding

DaveH: Where do we say that action is something that you dispatch off of?

Glen: It's not something we say - it's just a piece of information, and if you use it that way that's fine.

DaveH: Hmm - seems odd.
... The core says action is mandatory in the message - the WSDL gives you a way of putting that on a message - what's the relationship?

<uyalcina> ?p3 is umit

(group scans the spec, decides there might be an editorial issue here - we say action is associated with the WSDL value but not that you MUST use it appropriately)

<pauld> wsa => Web services Anarchy

<Paco> does anybody knows the call-in # for the 'WS-Anarchy' meeting?

(discussion of relationship between other specs and this stuff)

(Mark does some guerilla editorial work while higher-level discussion ensues)

Mark: Think we discussed whether UsingAddressing is SOAP-specific when discussion issue 21....

<mnot> i061 proposal:

<mnot> After first paragraph of Section 4.1, insert the following.

<mnot> The inclusion of wsaw:Action without inclusion of wsaw:UsingAddressing has no normative intent and is only informational. In other words, the inclusion of wsaw:Action attributes in WSDL alone does not imply a requirement on clients to use Message Addressing Properties in messages it sends to the service. A client, however, MAY include Message Addressing Properties in the messages it sends, either on its own initiative or as described by other elements of the servi

<mnot> Modify second paragraph in section 3.1 as follows:

<mnot> A wsaw:UsingAddressing element with a wsdl:required attribute whose value is "true" indicates that messages exchanged with the endpoint MUST have WS-A engaged (as defined by a binding of the Message Addressing Properties to a protocol). A wsaw:UsingAddressing element with a wsdl:required attribute whose value is "false" indicates that the endpoint will accept input messages with or without WS-A engaged. In the latter case, if WS-A is engaged, the use of the Messag

<mnot> If a SOAP binding is used and WS-Addressing header blocks are not present in an input message then WS-Addressing header blocks encoded in the corresponding output message MUST NOT be required to be understood using the SOAP mustUnderstand mechanism.

<mnot> [after "the inclusion" para] rdless of the presence or absence of wsaw:UsingAddressing. Other specifications defining the value of [action] are under no constraint to be consistent with wsaw:Action.

<mnot> [at end of "a wsaw:usingAddressing" para] Properties MUST be fully compliant with this specification; in particular, senders MUST use all Message Addressing Properties mandated by the [Core, Applicable WS-Addressing protocol bindings (e.g., SOAP), and this spec] and MUST follow all applicable WS-Addressing normative requirements. Such an endpoint MAY generate output messages with MAPs bound to them; however, if a message with WS-A engaged is sent to that endpoint,

<mnot> ages in [that exchange pattern] MUST also have WS-A engaged.

Jonathan reads some of the surrounding sec 3.1 text about UsingAddressing placement

(discussion of the definition of "engaged")

Mark: Are we ready to accept this text?

Jonathan: If I use wsaw:UsingAddressing in a WSDL HTTP binding, that's allowed but completely undefined, right?
... What happens if two different people define specs for the meaning of UsingAddressing in HTTP?
... OK, I'll raise an issue

Umit: (discusses whether the language allows other specs to "take over" the setting of action, overriding WSA)
... OK with this text, I might raise another issue

Mark begins to worry about the # of new issues

RESOLUTION: i061 is resolved by accepting the proposed text

Charter Requirements for WSDL Document

Mark: Let's talk charter requirements


(discussion of relationship between message props and WSDL service descriptions)

<scribe> ACTION: editors to ensure we meet our charter with regard to backward compatibility warnings for WSDL 1.1, aligining it with the direction we took for SOAP 1.1 [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action03]

Mark: So pending i059, have we met our charter requirements for WSDL?

Hugo: Was looking at sec 4 of WSDL binding (regarding relationship)... we relate MEPs and whether MAPs are mandatory or optional, but we don't link them to WSDL information....

(discussion ensues)

Hugo: OK, I'll reread the new drafts when they're ready and see.



Testing and CR

What is a testable feature? What's required / optional?


Mark: Lets start with broad outlines and then scope based on that. After that we can pick details.

Paul: SOAP binding pulls in the core implicitly - we're going to be testing "from the outside" and looking at messages.
... two multipliers - SOAP version for messages and transports you might exchange them on. Also WSDL version...

Mark: testing that it's implementable and interoperable - not testing every case necessarily
... not doing negative testing, etc

(discussion of conformance suite)

Paul: My company is looking for examples of things that work.

Mark: We can see about doing more work beyond the charter, but charter stuff comes first

Rebecca: What happens when WSDL gets through CR?

Mark: We might do fairly "light" testing with core/soap, and then real "end to end" stuff when WSDL is ready

Rebecca: So do we go over everything again at that point?

Mark: Implicitly at least

Glen: Not sure testing soap/core would really be "lightweight"

Mark: Should we, for instance, test async?

Glen: Nothing would prevent us from doing so...

Mark: Charter stuff has to come first. If extra stuff happens, that's ok, but we really need to focus on the minimum necessary to achieve victory.

Paul: Message exchanges I listed earlier are to some extent from Async TF - callback, for instance. That's perfectly testable now. What isn't yet testable is how you describe that in WSDL. I could see testing this kind of scenario with just core/soap....

(Mark draws Venn diagram of testable features inside implemented features)

Mark: we should consider testing stuff outside our core testable feature set, but we won't require it

Paul: I see the whole test suite having tons of tests, with only a subset of those being necessary for CR exit

Jonathan: It's important to get a seed started - endpoints that implement the basic tests. Once you've got that things tend to evolve....

<pauld> http://www.w3.org/2002/ws/addr/testsuite

Paul: this list is nice because we can use it to categorize the test suite. Nice to check "how many tests implement feature X", etc

(walkthrough of Mark's list)

(discussion of testing the "none" uri)

Arun: I note that we aren't mentioning securing MAPs...

Mark: Yep, but nothing in that section is really normative, so hard to test

(discusion of SOAP binding testing)

(only MUST in the faults is the InvalidAddressingFailure fault... others are optional)

DaveH: Hm - always thought that messageID must be present means we should throw a fault if it's missing...

Mark: IIRC, people wanted faults to be optional, had concerns if they had to be sent. That's how they got in.
... We do need to test them but we only need 2 interoperable implementations.

Paul: What happens if we don't get enough impls?

Mark: We'd need to remove those features, and go back to LC

Paul: This list isn't all the MUSTs and SHOULDs

Mark: Yes, but not all of those are testable... somewhat of a matter of opinion

(group looks at sec 6.3...)

Glen: This isn't good - some intermediaries might want to adapt req/resp to async one-way systems, and in those cases they will explicitly want to insert things like RelationshipType...

Mark: Perhaps you should raise a CR issue

(discussion of testing this)

Mark: testing this needs four intermediary impls, shouldn't be too bad

Anish: This was quite doable in SOAP 1.2

Paul: Need at least one test case for each feature, and several implementations.... so how do four impls interoperate?

Mark: Need four impls that demonstrate all the required features
... Will start scheduling time in concalls to discuss these things

Paul's Test Case Document

<pauld> http://www.w3.org/2002/ws/addr/testsuite

<pauld> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0036.html

<hugo> we're in case 2 in http://www.w3.org/2004/10/27-testcases.html#provisions; "If the Contribution is to be published by a Group in a Recommendation Track document that is not governed by the W3C Patent Policy, or if the Contribution is to be published outside a Recommendation Track document"

Paul: Passing the test suite isn't normatively saying that you conform to WS-Addr

Anish: Also, if you conform to WS-Addr you still might fail some tests....

Paul: Would like to revisit metadata/categorization in light of the discussion we just had

<anish> There are a few paragraphs in the introduction section of http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/ that can be adapted for ws-addr and used for our test suite

(discussion of top-down approach to testing vs. bottom-up)

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing-tests/2005Aug/0000.html

(discussion of test formats/template, how to get lots of submissions that don't cover exactly the same things, etc)

Mark: I'll drive the discussion from this list in the WG, and Paul can get together a solid, well-framed test suite.
... any comments for Paul?

Group: good job :)

Paul: Wanted to make sure I covered everything Arun sent

Mark: No telcon next week, but if we could have the WSDL async proposal by the following mon that would be great.
... after discussing that we move on to testing in earnest.

<scribe> ACTION: Arun to iterate his testing document to categorize and reformat by next telcon [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action04]

(discussion of using XPath to indicate test success/failure states)

(discussion of schedules, PR timing, etc)

<pauld> http://blog.whatfettle.com/archives/000033.html

(discussion of meeting scheduling)


Summary of Action Items

[NEW] ACTION: Arun to iterate his testing document to categorize and reformat by next telcon [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action04]
[NEW] ACTION: editors to ensure we meet our charter with regard to backward compatibility warnings for WSDL 1.1, aligining it with the direction we took for SOAP 1.1 [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action03]
[NEW] ACTION: Jonathan to formulate a proposal for a migration guide [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action01]
[NEW] ACTION: proposal to address the issue of how to solve issue i059 for wsdl11/soap11 and figure out how the WSDL extension would look like [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/10/19 18:59:35 $