See also: IRC log
<Paco> Scribe: Paco
Chair: let's pick up issue 51 where we left
Hugo: we discussed mapping of
OAPAction and WSA Action
... proposal is that if SOAPAction (v1.2) is present it must match the value of WSA Action
... SOAP 1.2 is done deal; SOAP 1.1 is trickier
SOAP 1.1: there is a third option different from present and absent: ""
Hugo: WS-I BP does not allow
... I proposed 5 options
... we can align with BP but we'll violate SOAP 1.1
Greg: wasn't BP supposed to clarify SOAP 1.1? I'd rather align with that
Hugo: my option 2 is not
... option 3, not allow ""
Umit: in 3, what the required value is?
Hugo: same as wsa Action
... Actually, either they match or there is an empty value for SOAPAction
Chair: Hugo, can you explain the consequences of each option for SOAP 1.1?
Hugo: By BP you always have to
specify it; Steve had an idea...
... either you have a matching value or we define a URI value meaning "empty"
Anish: Had similar discussion with Mark; the URI would mean that wsa action actually provides the value
Marc: doesn't that violate the aim of SOAPAction?
Anish: this cover the case when you don't want to expose the value
Jonathan: this would not work with existing SOAPAction implementations
Chair: seems people object to semantics in the second case
Glen: are the semantics of both
properties actually the same? Since there are so many cases and
... shouldn't we admit they are different things?
Chair: we have 7 pending issues; is this one critical?
Hugo: SOAP 1.1 says Action
describes the intent of the message; SOAP 1.2 is fuzzier
... for SOAP 1.1 they really look like the same thing
Greg: is SOAP action the abstract
property or the serialized value of SOAPAction
... the enveloping model means the envelope needs to be able to stand alone
Tom: WSDL tells you what each
action needs to be - one could specify different values
... I am starting to agree with Glen
Anish: I'm ok as long as I am not
required to specify the http SOAPAction
... how does option 3 works with BP 1.1
Jonathan: it does not
Paco: should we decide not to say anything, we may not be really helping
Umit: I disagree, people are going to ask what is the relationsip
Tom: we may want to leave room for profiling
<umit> i am suggesting we put a recommendation to indicate that they should be the same, but not a MUST
Philippe: we are here to make it work
Tom: but what would be broken?
Chair: I am surprised no one
thought that the BP should change instead of wsa
... sounds like there are 3 options:
... Hugo's option 3
keep the status quo
Chair: second is keep status
... third is change MUST to SHOULD
Greg: are we going to invalidate all existing WSDLs?
Marc: the binding would tell you what the value is
Chair: option 4 is the new URI to
... there are 2 flavors for #4
Anish: a version of 3 is make no mention of any constraint/recommendation
Chair: straw poll: 1) 8 in favor, 15 can live with
Glen: 2 is actually the same as 1, for SOAP 1.1?
Greg: 1 explicitly violates BP 1.1, 2 does not
Chair: do we understand what 'must be empty" mean?
Hugo: "" is disallowed
Anish: it is not disallow, although is may be weird
Chair: "" is a relative URI so it
defaults to the request URI
... rewrites #1: contrained the requirement to the header field, not the derived value
Anish: relocating the service changes the derived SOAPAction in the "" case, so you get a mimatch with wsa Action
<Chair> Option 2: When issuing a SOAP HTTP Request, the value of the SOAPAction (after "" defaulting) MUST either be equal to the value of the [action] message addressing property, or MUST be empty.
Chair: should we clarify in #2
that the SOAPAction value compared is the one obtained after
... note that now "" is disallowed
... in option 1
... voting for option 2) 2 in favor; 12 can live
<Chair> Option 1 (revised): When issuing a SOAP HTTP Request, the value of the SOAPAction header field MUST either be equal to the value of the [action] message addressing property, or MUST be empty. ("" disallowed)
Chair: back to option 1 since it
changed - posted in IRC
... vote for #1: 3 in favor; 14 can live
... does option 3 make sense?
Umit: yes, if you remove the 'must be empty'
Chair: removes "must be empty",
other must becomes a should in option 3
... vote on #3: 4 in favor, 19 can live
... option 4: 0 in favor, 20 can live
... option 5, 7 in favor, 18 can live with
... negative votes? for #4, who could not live with #4?
Paco: can't live and no are different
Chair: taking out 4, nobody
expressed preference for it; seems like it is either 3 or
... voting 3 or 5: 17 for 3; 3 for #5; abstentions we have missing votes, but clear preference for #3
... summarizing: we agreed ot ad dfeature, properties and took Hugo's part 3 out
... we just replaced that by option #3 above
MichaelE: we need to give instructions to the editors about removing SOAP stuff from the core
Hugo: part of issue 51 may be related ot Mark Baker's issue
Chair: I spoke to him, seems
there is no SOAP destination property that creates a
... it may come up again when we talk about logical addresses
... can we close issue 51 with the proposal as described?
<Chair> Option 3 as accepted: When issuing a SOAP HTTP Request, the value of the SOAPAction (after "" defaulting) SHOULD be equal to the value of the [action] message addressing property.
Chair: we close issue 51, moving on to issue 7; Hugo had an action
Hugo: think so
<MSEder> Add to the core document some basic guidance regarding how to handle this issue if the what Addressing is bound to has an action.
Hugo: proposal had a bug, sent
amendment, check 2nd url
... my proposal talks about sending, receiving messages, not intermediaries
... spec only talks about to and ref. params, not other properties; does not talk about receiving messages
... core spec is missing infoset serialization for ref. params in message
... and put this in the core
... when receiving message, do inverse - properties take values from serialized infoset
Glen: we should alter the syntax of wsa:type now that we don't have ref. properties
Hugo: I proposed 3 rules but
there is a problem with #1; intermediaries would then have to
forward all headers
... not remove them
<Chair> Modified Proposal: http://www.w3.org/mid/20050224134944.GK16108@w3.org
Glen: we can solve it saying that it is one's chioce whether to forward properties
Anish: if ref. param is targeted
at intermediary it should be removed
... abstract properties can be populated before or after soap headers are processed
Glen: the result of the processing is precisely populating those properties
Geln: intermediary processing model is unclear
Glen intermediary can decide what to do; header is in abstract bag and available to be sent again or not
Marc: get rid of point 2 in the
... let the intermediary do its SOAP processing , what else is needed?
Glen: that is why we put the wsa:type property in the first place
Paco: we sould not go on defining how people use the type attribute, thatis application specific
Marc: add 'targeted at the node' in point 2
Glen: that is implied
Umit: no, it is not
Paco: minter of the EPR knows processing model of intermediaries, intermediaries need not be aware of anything else
Glen: intermediary will see wsa:type attribute and needs to know what to do
Chair: break at 10:40, back at 11
<hugo> i007 new proposal for discussion: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0002.html
Chair: Hugo sent an updated proposal
Hugo: updated the syntax of
... did not change sending the message part
... populating abstract properties is not an issue really: implementation make choices of whether to expose the properties or not
... so implementations can ignore #2
Glen: the issue is when a second spec depends on abstract properties, and needs access to the right values
Hugo: in point 2, wsa:type
enables to to populate ref. param values
... in 3, just do standard SOAP processing on headers
... it is unnecessary, unless you mean process ref. params as normal
... but you could decide not to... so remove #3
Marc: this looks like an extension of the SOAP binding, not a straight application of the SOAP proc. model
Glen: when there are ref. params then the base model is not enough
Marc: SOAP proce. model implies thatthe processing can be derived from the headers themselves
Hugo: difference is really stylistic
Marc: need to write wsa as an active intermediary - which is why I said it is at the binding
Hugo: question is what triggers all those rules
Glen: is Action targeted at intermediaries as well?
Marc: we haven't discussed this at all
Glen: it is ok to say that if you are wsa compliant this is hwat you do
and if we end up saying that wsa action is always targeted at internediaries then we can say that is what triggers processing
Anish: do we say anythign about what wsa-ignorant SOAP modules do when a header has wsa:type
Glen: no we don't
Chair: this was decided when closing issue 8; we chose not to require people to understand
Glen: replace "not in the general case" for "do not necessarily"
Jonathan: is there an implication that all ref.ps make it to this level to be extracted?
Hugo: we should say "targeted at the node" at #2
Jonathan: why are we doing this?
Paco: what are the interop consequences, I think none.
Glen: there are implications if other specs rely on wsa
Paco: this is implementation, not visible behavior on the wire
Greg: it is architecture, no interop consequences
Glen: I want to be able to write code that accesses and refers to those properties so we need to provide access to them
Hugo: allows one to be very concrete about what the properties are when you receive them
Jonathan: we should not do it
Glen: it is debatable if this has interop consequences
Chair: Anish, Hugo, Glen, Mark are you ok with the modifications proposed here?
Jonathan: I support the proposal is we strike 4.2
Marc: there is an issue of whether in 4.2 the property is actually the same as in 3 (when sending the message)
Chair: Anything else we need to cnsider?
Marc: yes, targeting?
Jonathan: since we don;t have a proposal that will not happen today.
Hugo: I won't object if we decide to strike 4.2 even if there are reasons to do it
Chair: straw poll about removing 4.2 from proposal
Marc: this makes this property a sender's only property
<dorchard> darn, I'm missing something here...
Anish: you can tell what params survived
Jonathan: you may not come ou twith the same properties that you started because intermediaries may consume them
Chair: prefer to remove 4.2: 10;
prefer to keep: 3; abstain: 8
... actualy 9 abstentions (one on the phone); clear desire to remove
... targeting headers - we already can target ref ps, do we provide guidance to targte the other headers?
Glen: I sent a proposal: can add attribute on the EPR to indicate where to target headers
Jonathan: I thought we decided not to add mechanisms to target EPRs, but we don;t preclude ref. ps from being targeted
Marc: if you process Action do you need to reinserted
Chair: spec says the aim to target end-to-end
Marc: not just the EPR but all
... we don;t say anything and this means ultimate receiver; we may prefer to explicitly allow targeting
Anish: othe option is target to
next and relay=true
... in that case the semantics is to reinsert
Glen: we should allow multiple To
... I don't want to define message path but I want to allow routing on top of wsa
Marc: you target mail to ultimate destination
Chair: 3 options: target to
ultimate receiver; 2 provide mechanism to target to
... target to ultimate r but allow changes in the future;
Anish: 4 is next+relay: if you understand and process you reinsert
Jonathan: 3 could be that the epr has an indicatio to target to other nodes
Chair: 3 is like 2 but we don't
do the job
... got rid of option 1; renumber accordingly
MarcH: difference between 2 and 3 (new #s) is that in 3 each intermediary by defaults get the headers; not in 2
Dave): you support 3 if you like routing
Glen: 3 does not support source routing
Anish: how does 3 works for SOAP 1.1
MarcH: there is still the problem of understanding but not processing
Chair: no difference in 1 and 2
for 1.1 and 1.2
... we need wsa:To mustUnderstand=
Chair: in 1.1 you ave actor=next, mU=true
DaveO: if you have an intermediary and you want the message to relay you need ot upgrade your intermediary
JeffM: if you don;t want to go to SOAP 1.2 you need to do something else to make 3 work
Chair: new option 4 is to default to #2 in case of soap 1.1; in option 3 we specify forwarding semantics and mU=true
Hugo: concerned with having different approaches for different protocols
Chair: poll: option 1, 0 in favor, 3 can live; #2 13 in favor, 22; #3 1 in favor, 13 can live with
Chair: #4, 3 in favor, 17 can live with.
Chair: choice is betwee 2 and 4;
vote again: 13 for #2, 4 for #4, 5 abstain
... seems everyone can live with #2
... that takes care of the targeting
... does Hugo's edited proposal plus the targting approach just accepted constitute an acceptable resolution of the issue?
Anish: do we need point 5 anymore?
Glen: there is no harm in leaving it there
Anish: does this say anythig beyond soap processing model
Anish: soap processing defines what is processed regardless of any extensions; rules are clear for intermediaries
Glen: just because you populate the abstract model you don't process or forward all those headers
Jonathan: how important is this?
Anish: I am ok if Glen really wants it
Chair: so we have a proposal to close issue 7; any objections?
Glen: yes, 4.2 should not have
... record I am not happy - done
Chair: talk for a few minutes
about issue 22 before lunch
... some people believe we needed a module; others that it is necessary to describe in detail the behavior implied by wsa
... Is there another aspect that would need to be addressed?
Greg: I want to understand how things map to WSDL, SOAP, transport
Chair: we need to know what are the requirements on MEPs and use patterns
Anish: do we need to address DaveO's proposal to close thi issue?
Jonathan: we need to decide if there is anything that we can do to our documents to close this issue
Chair: goes over remaining issues
in the agenda that are posisble blocks ot last call
... maybe we can have a last call next or following week
... if Marc can incorporate all issues by then; review and vote
... break for lunch, back at 1:20
<rsalz> scribe: rsalz
Chair: fait accompli we're going
to describe a soap module.
... okay to leave it for the editors?
hugo: yes, but we should give a URI to the soap1.1 extension
Chair: do anything for soap1.1? if so, re-use the 1.2 uri?
hugo: don't re-use uri
mhadley: does that mean we define them in separate sections, duplicate the wording, etc?
hugo: we're going to have to separate them anyway
dorchard: document default behavior and separate them?
Chair: anyone other than hugo feel need for two uri's?
hugo: he can live with just one uri
glen: single uri has two sets of semantics.
Chair: anyone object to this as partial resolution to i022?
nobody objects, Chair will send email to list with revised proposal
glen: will summarize TF and
enumerate the questions they came up with.
... focus of discussion was on use cases; how do people want to use this spec?
... For example, WSDL has a one-way MEP, but no way to bind that to SOAP.
... Using ReplyTo could be a one-way. How can you look at WSDL and see that that's supported?
... Much of this stuff really "belongs" in WSDL or SOAP group, although we can help out. That is, it won't hold us up (not our job), but the community needs this done.
See http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0001.html for list of questions.
glen: This discussion will
continue in WSDL WG; some chat with SOAP WG, too.
... There doesn't seem to be any work for WS-A to do in order to enable this; burden seems to be on the other WG's.
Anish: Could define multiple bindings (HTTP, SMTP/response) which has combinatorial issues.
Glen: If you define a "floating" (composable, run-time), that id's markers in the message for transport.
Identified a question: can you express it in WSDL 1.1 (does it have enough/the right) extensibility points?
Anish: we have decisions wrt. who should do what... there are things that XMLP could do.. or WSD can do.. or things that WSA can do. Question is... if we find out that there are things that can be done wrt. SOAP or WSDL 1.1, is this the working group that would do it?
Mark: it's just as much in scope of XMLP.... We are kind of drifiting into this discussion.
Paco: Anish's point is specific to WSDL 1.1
Mark: was there any discussion in the TF about parity, and equivalent discussion?
Glen: there was concern at the beginning, but no discussion on this
Anish: WSA is the only group that has SOAP 1.1 and WSDL 1.1 in itls charter...
DavidO: his point is that WSA, wrt WSDL 1.1,is in the scope of this group... it's not to do the errata.
Anish: I'm now saying it's in the charter... if we really wanted something wrt. WSDL 1.1., the best chance is to have this group to do something about it
Jonathan: I don't think I agree w/that.
Glen: I would like to see the TF to remain and act as a facitlator to this discussion
TF already has members of XMLP, WSDL, WS-A
glen: More people than just the
TF members have opinions.
... Want non-TF folks in each WG to get involved.
hugo: There's nothing on critical path for last call; some annoying things (e.g., one-way binding) that will come up during CR stage.
Dicussion of closing i022 now; is leaving i021 open enough for now?
Discussion of considering another deliverable, a collection of usage scenarios and how to use WS-A to achieve them.
A set of recipes, or a primer, similar to dorchard's examples.
dorchard: If there were a WS architecture group, they could own the primer, but it seems that WS-A should own it.
Is it a non-normative primer, or a document with MUSTs, etc., that say how something *is* to be done
Chair: Straw poll -- Who thinks that delivering something like this (details TBD) is important for the success of WS-Addressing?
Results are 21 yes, 2 no, 1 abstain
Chair: Straw poll -- is having something like this critical for exiting CR?
glen and jeffm clarify the question to explain that this is part of the QA/interop testing
Chair: Is "this work" important enough to hold up at least one document from exiting CR?
Results are 17 yes, 4 no, 2 abstain
dorchard: Test suites and scenarios are targeted to different audiences
Chair: A WG Note is the next level of document type and seems appropriate for "this work". A WG Note isn't by default part of the patent policy
Would have to resolve patent policy issues if we go this way
Chair: An official recommendation from the WG would probably require a charter change.
jeffm: want scope of new doc resolved before going to last call
phillipe: want scope resolved before exiting last call
Chair: with my chairman hat on, i want the async-tf to continue
glen: will coordinate the work, but not be decision-maker. izzat cool with all?
paco points out that dependency on wsdl and xmlp is important
Chair and glen point out that we have to decide if that's important to us before we enter CR.
Chair: issue i022 is a poor proxy for the dependency concerns. can we close i022 with the module proposal? no dissent, i022 closed.
hugo: Took Gudge's text, Paco's amendment, current text and wrote a new security considerations proposal.
dhull: question about where the trust relationship holds?
Added revised wording from jmarsh about message-id and need for other data to address reply issues
paco: if epr has a replyto sending to a third place, make sure that you can trust the info to send to it
more discussion about trust; details not captured as scribe was involved. :)
dhull: subscription request use-case as another example, particularly where determining trust is determined very late in the game.
Much group wordsmithing of the security considerations proposal.
dicussion of hugo's proposal for the SOAP binding security considerations text
mhadley wants to see a concrete example of signed/secured EPR
dorchard says that wouldn't necessarily force us to re-start LC
Chair: w3team agrees this is a
feasible LC call issue; mhadley agrees to do so at that
... formal vote: accept proposed text to close issue i004
results 12 yes 2 no 4 abstain
Chair: issue i004 is closed
... less than an hour left; issues to address i049 i050 i052 i020. will do status-check at 5pm
issue and proposal at http://w3.org/2002/ws/addr/wd-issues/#i049
Chair reminds jmarsh that WG polled and gave mhadley AI to write his proposal (#3 at url above)
paco and jmarsh discuss mhadley vs jmarsh proposal
Chair: straw poll of three options: mhadley, jmarsh (remove the "messaging" URI and text from mhadley), or abstain.
both 11, just-faults 6, abstain 5
Chair: straw poll do both or do nothing
results do both 9 do nothing 7 abstain 8
Chair: formal vote close i049 by accepting mhadley's proposal
results 6 yes 7 no 5 abstain
decision: issue i049 closed with no change.
hugo: Walked through his proposal; see http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0101.html
jmarsh: propose amendment "if faultto is absent, send to replyto if present"
umit raises issue of WSDL 2.0 rules for faults and MEPs
dhull: don't specify too much and thereby preclude bindings
paco: keep replyto mandatory. faults are unexpected, which is justfication for asymmetry of handling.
seem to have consensus to accept jmarsh's amendment
hugo: for classic http-based MEP, replyto isn't needed.
paco says there are two issues: clarification (he thinks it's needed), and asymmetry (he thinks it's fine)
Chair: straw poll in favor of #3 ? 12 yes, 8 no 1 abstain
<scribe> ACTION: jmarsh to propose concrete text for proposal 3 to close i049 [recorded in http://www.w3.org/2005/03/01-ws-addr-minutes#action01]
<pauld> i blogged on this: http://blog.whatfettle.com/archives/000244.html
paco: has alternative proposal to remove the second proposal
umit: agree with paco. avoid dangerous waters
anish: motivation was confusion
(for non-wg members) about difference between logical and
... i could be okay with paco's proposal, but prefer my clarification of the current intent
paco: it's just a uri; what value do we add by the description?
anish: previous versions of the spec say it *was* dereferencable; this makes it clear that it's not (now)
dorchard: we have a thing called an address, but we're avoiding saying what it is
Chair: straw poll anish's proposal, paco's proposal, or abstain
results anish 4 paco 11 abstain 7 (includes neither one is acceptable)
<scribe> closed issue i052
<scribe> ACTION: mhadley to make sure that he recorded text of paco's proposal [recorded in http://www.w3.org/2005/03/01-ws-addr-minutes#action02]