Web Services Addressing WG Face-to-Face

<Paco> Scribe: Paco

issue i051

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0210.html

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 empty value
... 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 acceptable
... 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 exceptions
... 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 quo
... 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 mean 'empty'
... there are 2 flavors for #4

Anish: a version of 3 is make no mention of any constraint/recommendation

<bob> +1

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 defaulting
... 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 5
... 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 conflict
... 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

issue i007

<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> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0186.html

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0187.html

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/[email protected]

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

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 proposal
... 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 wsa:type attribute
... 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

Glen: disagrees
... 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> http://ezine.nitroexpress.com/200412/bigcat.wmv

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 MAP
... 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 headers
... 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 others;
... 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 true

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

Glen: yes

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 been removed
... 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

i022

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

asynchronous task force

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.

Nobody disagrees.

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.

issue i004

<pauld> http://dictionary.reference.com/search?q=entropy

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. :)

<<break>>

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 time
... 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

i049, default default action uri for fault messages

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.

issue i050

see http://w3.org/2002/ws/addr/wd-issues/#i050

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]

i052, what is a logical address?

See http://w3.org/2002/ws/addr/wd-issues/#i052

<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 network address
... 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]