IRC log of ws-addr on 2005-03-01

Timestamps are in UTC.

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