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