See also: IRC log
<Arun> I will not be able to join via phone or in person today but will be available on IRC
<dorchard> scribe: dorchard
<GlenD> Meeting: WS-Addressing Face-to-Face, September 28, 2005
<GlenD> Chair: Mark Nottingham
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
Paco runs through his proposal.
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0037.html
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 guage 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/
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0062.html
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
marsh: outlines difficulty of migrating from addressing member submission to our rec in area of wsa:action
http://www.w3.org/2002/ws/addr/wd-issues/#i064
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"
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?
NONE!
who would lie down in the road for 3?
4
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
dhull:
<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
BEA - N
BT - Y
CA -abs
Ericsson - N
Fujitsu - N
Hitachi - N
HP - abs
IBM - Y
IONA - Y
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
SONOA - 1
TIBCO - 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
http://www.w3.org/2002/ws/addr/wd-issues/#i064
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
<yinleng> \me Is the meeting over yet?
meeting ajurned with photos
<mnot> Meeting: Web Services Addressing Face-to-Face
<mnot> Chair: Mark Nottingham
<mnot> Agenda: http://www.w3.org/mid/D98ACD86-AAC1-405F-BD05-3CE8D3B63980@bea.com
<anish> Scribe: anish
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0033.html
Discussion about the f2f meeting after the Japan f2f
Mark: after that very likely in Vancouver, BC
<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
----------------------------------
BREAK
-----------------------------------
BACK FROM BREAK
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
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
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
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
---------------------------
LUNCH
---------------------------------
<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
<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
mnot: CR2 Next
hugo: We had decided to decide on this issue much later
mnot: Moving on to CR3
<vikas> http://www.w3.org/2002/ws/addr/cr-issues/#cr3
<bob> ping
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
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
mnot: Next is Umit's anon URI issue
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..."
<vikas> Next is 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.
mnot: Next is Hugos' 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
<vikas> Next is dhull's 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:
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0100.html
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
}
else
{
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
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0100.html
<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 Bindinging 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
<vikas> will continue on this issue tomorrow morning
<vikas> *************CLOSE OF DAY 2*******************
<GlenD> Meeting: WS-Addressing Face-to-face
<GlenD> Chair: Mark Nottingham
<GlenD> Scribe: Glen Daniels
<GlenD> Scribe: GlenD
Mark: Let's see what we can do about i061, shall we?
(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
Mark: Let's talk charter requirements
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0031.html
(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.
BREAK
RESUME
What is a testable feature? What's required / optional?
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0034.html
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
<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)
ADJOURN