20:35:23 RRSAgent has joined #ws-addr 20:35:23 logging to http://www.w3.org/2005/12/12-ws-addr-irc 20:35:26 zakim, this will be WS_ADDR 20:35:26 ok, mnot; I see WS_AddrWG()4:00PM scheduled to start in 25 minutes 20:35:38 Meeting: Web Services Addressing Working Group Teleconference 20:35:42 Chair: Mark Nottingham 20:35:55 Agenda: http://www.w3.org/mid/1254903C-8804-4DA8-95DA-484103D8E82B@bea.com 20:41:50 David_Illsley has joined #ws-addr 20:42:27 Jonathan_Marsh has joined #ws-addr 20:47:35 TonyR has joined #ws-addr 20:49:48 TonyC has joined #ws-addr 20:52:03 PaulKnight has joined #ws-addr 20:53:17 TRutt has joined #ws-addr 20:56:35 prasad has joined #ws-Addr 20:57:06 Nilo has joined #ws-addr 20:58:35 WS_AddrWG()4:00PM has now started 20:58:42 +Paul_Knight 20:58:49 Katy has joined #ws-addr 20:59:09 Bozhong has joined #ws-addr 20:59:30 +Nilo_Mitra 20:59:35 +Bob_Freund 20:59:44 bob has joined #ws-addr 21:00:23 +David_Illsley 21:00:36 +Mark_Little 21:00:50 +Gilbert_Pilz 21:01:07 +TonyC 21:01:23 +Tom_Rutt 21:01:26 +Mark_Peel/Katy_Warr 21:01:31 +??P10 21:01:34 +Bozhoirg 21:01:36 -??P10 21:01:49 that's bozhong 21:01:56 +??P10 21:01:57 +MarkN 21:02:21 +Dave_Hull 21:03:19 +Prasad_Yendluri 21:03:21 dhull has joined #ws-addr 21:03:34 +Pete_Wenzel 21:03:42 +Jonathan_Marsh 21:04:06 vinoski has joined #ws-addr 21:04:06 +??P16 21:04:16 zakim, ??p16 is me 21:04:16 +TonyR; got it 21:04:39 +Anish 21:04:46 uyalcina has joined #ws-addr 21:04:54 anish has joined #ws-addr 21:04:58 +??P18 21:05:08 +Umit_Yalcinalp 21:06:24 swinkler has joined #ws-addr 21:08:38 +??P20 21:08:48 scribe: dhull 21:09:17 +Steve_Winkler 21:09:32 Zakim, Steve_Winkler is me 21:09:32 +swinkler; got it 21:10:14 Marsh has joined #ws-addr 21:10:26 Action: Approved minutes 11/28 21:10:43 ACTION: Approved minutes 12/5 21:11:34 +Dave_Orchard 21:12:26 TOPIC: testing 21:13:17 mikep: Working toward public endpoints prior to F2F, some preliminary interop before F2F, aiming to satisfy requirements in Jan 21:13:52 dillseley: Planning on endpoint in next couple of weeks 21:14:16 markn: WSO2 is planning on joining for testing 21:14:50 TOPIC: Issue 66 21:15:10 mnot: Owner will be Marsh 21:16:06 mnot: No calls between next week and Jan 9 21:16:13 TOPIC: I 059 21:16:35 mnot: Understanding is there are two general areas of discussion 21:16:46 mnot: 1) dhull proposal for SOAP 1.2 21:16:54 mnot: 2) disposition of SOAP 1.1 21:17:21 mnot: 1 is proposal 4. Fulfilling the need to incorporate SOAP 1.2 into proposal. 21:17:53 Dhull: Walks through the proposal 21:18:10 ... early part of section 3 is what markup we use and how it fits into the WSDL model. 21:18:26 ... section 3.1.2 talks about a modification to the HTTP SOAP 1.1 binding. 21:18:44 ... this proposal talks about how to map the WSDL 2.0 meps to the SOAP 1.2 adjuncts 21:18:56 ... assumes there will be a one-way mep produced at some point. 21:19:13 ... all this is is three short rules. 21:19:15 http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/att-0093/WSDL20SOAP12.html 21:19:38 ... In response to some feedback from MarcH I rearranged this slightly. 21:20:12 ... Need to figure out what to do at the transport level. you need to look at the WDSL MEP, what bindings you have in effect, and rules to tie all this together. 21:20:52 vikas has joined #ws-addr 21:20:58 ... You either have a SOAP req-resp happening, in which case we bind to the SOAP req-resp mep 21:21:15 ... Otherwise you have to bind to two one-ways. 21:21:36 ... You have to conform to the one-way in each direction. 21:23:11 Umit: I couldn't really fit this into the write-up style of the async proposal. Here you are talking about SOAP req-resp, and instead of taking it from the anonymous perspective you talk about binding to one-ways. 21:24:11 Dhull: Slightly different - there isn't a framework of MEPs in SOAP 1.1 to fit into. In SOAP 1.2 you have the req-resp MEP defined, and it sounds like you'd have me talk about what the anonymous endpoint means, which has proved a rathole. 21:24:30 gpilz has joined #ws-addr 21:24:33 ... Instead you talk about the behavior keying off of anonymous. It's a cue to use the req-resp mep. 21:24:51 Umit: That's right! But doesn't come across in this write-up. 21:25:23 TonyC has joined #ws-addr 21:25:31 ... Write-up starts with anonymous markup, behavior follows. 21:25:34 q+ to ask if "SOAP one-way" is used generically 21:25:50 DHull: I think that's all implicit, fine with making it more explicit. 21:26:31 ... When WS-A is engaged, with anonynous="required", you always fall through to 3.1.3.1, use req-resp mep. 21:26:43 ... The chain determines this but it might not be obvious at first. 21:27:38 Umit: Write it so that instead of a separate section you could follow the same logic for what anonymous='required' means. 21:28:02 ... for SOAP 1.1 and 1.2. 21:28:02 DHull: You get the same logic in either case. 21:28:16 Umit: The one-way mep doesn't exist today... 21:29:31 DHull: You'd like to see this broken down by when anonymous is constrained. We can just add to my text a note to that effect. 21:29:43 Umit: Right now these two write-ups don't hang together well. 21:30:20 ... If I have anonymous constraints in the WSDL, how does that work with this? It's impossible to figure out. 21:30:32 DHull: Not impossible, just walk through the rules. 21:30:32 jeffm has joined #ws-addr 21:30:44 Umit: If I don't use this I can't use SOAP req-resp MEP, right? 21:32:10 DHull: Would you consider these problems as sturctural or editorial> 21:32:14 Umit: not sure 21:32:14 ack anish 21:32:14 anish, you wanted to ask if "SOAP one-way" is used generically 21:32:35 Asnih: When you refer to the SOAP 1.2 req-resp MEP, you might want to use the URI for the MEP. 21:33:04 ... What did you mean by one-way MEP? Does it include the new one the XMLP WG may define? 21:34:23 q+ 21:34:33 +Gilbert_Pilz.a 21:34:33 DHull: Doesn't think it's the SOAP Response MEP, but the new one-way MEP from XMLP. Most plausible course of action is to make sure we don't hang the whole thing on the XMLP MEP. 21:34:40 +??P29 21:34:44 -??P29 21:34:53 s/Asnih/Anish/ 21:35:20 +??P25 21:35:39 Anish: You're talking about how an exchange can be realized with one or two MEPs. The SOAP Response MEP would be disallowed? 21:36:28 DHull: Depends on how you're defining the polling case. The typical case where there are two HTTP connections, the second post would not be an example of the response mep. 21:36:41 ... One way of modelling that is considering the poll and the response as an instance of the Response MEP. 21:36:57 ... The other would be to say the Response MEP can be considered a one-way. 21:37:23 Anish: I was thinking along those lines when the requester is behind a firewall a callback can happen. 21:37:27 q? 21:37:41 ack uyal 21:38:16 Umit: This proposal isn't complete. You say the WSDL MEP will be realized as either one or two SOAP MEPs. When one MEP is relevant isn't clear. 21:38:20 s/callback can happen/callback cannot happen/ 21:38:28 ... You say you must comply with the SOAP one-way MEP - which isn't defined. 21:38:43 ... So what can you do here? 21:39:06 DHull: Assume for our testing purposes the one-way over HTTP is a POST and a 202 return. 21:39:15 MNot: Concerned about testing it? 21:39:17 Umit: Yes. 21:39:29 DHull: I rewrote this on the assumption that the one-way existed. 21:39:41 ... Screened off the elephant in the room. 21:39:48 + +1.619.291.aaaa - is perhaps Liam? 21:40:20 ... In the case of one or two MEPs, it is implicit in the text. You can enumerate the cases where there will be one or two MEPs. 21:40:38 ... One mep in in-only, robust-in-only when there is no fault. 21:41:03 MNot: How complete is this? Are folks uncomfortable with the general direction? 21:42:17 Umit: Who decides on the one-way mep. There are other groups like ws-rx that depend on the binding of anonymous - e.g. an envelope returned from a soap body in it. 21:42:37 DHull: Recognize this is useful. 21:43:10 ... I think I'd say this looks like a SOAP req-resp at the SOAP level - in which case we'd have to revisit this rule. 21:43:24 q+ 21:43:31 ... We'd have to make a call on whether the anonymous was used for an unexpected purpose. 21:44:02 ... Think I'd lean towards considering that case as a req-resp. 21:44:11 s/soap body/empty soap body/ 21:44:34 q- 21:44:40 MNot: We're in a place where we need to coordinate with XMLP. 21:44:52 gdaniels has joined #ws-addr 21:44:54 ... How close are we to going to last call? 21:45:07 -Mark_Little 21:45:28 q+ 21:45:39 ... Are we in a place we're ready to incorporate Umit's and David's addendums into the spec and ship as last call? 21:45:53 q+ 21:45:57 DHull: I'll gladly take an action to look carefully at 3.1.3 better in line with 3.1.2. 21:46:26 ... Is there a procedural way to mark this section "at risk", in order to prevent it from being an obstacle at last call. 21:46:48 MNot: We have a dependency on XMLP. We'd have to note that in the document. 21:46:58 q? 21:47:05 ack dhull uyal 21:47:17 ack dhull uyal 21:47:17 ack dhull 21:47:17 ack uyal 21:47:31 Umit: Why don't we divide and conquer? The issue is SOAP 1.2. We made a lot of progress with SOAP 1.1, and clearly mark the SOAP 1.2 part as subject to change depending on what XMLP comes up with? 21:47:39 ... I don't have a good sense of the XMLP timeline. 21:47:56 MNot: We're already dependent upon WSDL doc on WSDL 2.0. 21:48:23 Jonathan_Marsh has joined #ws-addr 21:48:40 scribe: dhull 21:48:53 +[IPcaller] 21:49:13 mnot: take umits point about divide and conquer, but would be concerned about needing to wait 21:49:22 andreas has joined #ws-addr 21:49:32 umit: WSDL 2.0 is way ahead of XMLP, so XMLP dependency less of a concern 21:49:47 mnot: Even if we go to LC now or soon, there will still be time 21:50:04 mnot: XMPL LC Feb-Mar would not hold us up. 21:50:14 anish: hard to say 21:50:25 TRutt has joined #ws-addr 21:50:26 anish: XMLP will be F2F at plenary 21:51:01 anish: Seems like reasonable thing to do. Requirement for one-way is submitted to XMPL, requesting timely response. OK to assume they do this. No indication they can't. 21:51:17 mnot: Publishing this as LC would give them something to shoot for. 21:51:50 anish: At least we get the rest of this stuff out for comment. 21:52:26 mnot: Can ask if editors feel comfortable (after 66) folding in these proposals. 21:52:41 marsh: Is this absolutely fundamental? What if XMLP doesn't converge? 21:52:58 marsh: Can we insulate by referring to "one-way" generically 21:53:06 mnot: could publish but could we test? 21:53:07 q? 21:53:12 q+ 21:53:42 dhull: could we note assumptions made for testing? 21:54:18 mnot: If XMLP doesn't work out, we need to figure out different way, or go to WD again. If this happens, us going back to WD is understandable. 21:54:35 marsh: worry is that people would interop to this and XMLP would contradict this. 21:54:49 mnot: if we can interop and XMLP doesn't say anything, what's the problem? 21:55:44 daveo: Key here is notion of MEP to insulate us from binding. Could have several different bindings, same functionality, interoperability. As long as wire behavior is the same, we're OK. We could easily specify a one-way MEP for insulation 21:55:58 daveo: Then say that actual binding has to be equivalent. We get interop. 21:56:17 dhull: basically what non-normative note in original proposal was aimed at. 21:57:11 mnot: Seems like we can push to close i059 with what we have so far and go to LC somewhat aggressively so we can coordinate, and there are a couple of paths if that doesn't work out. 21:57:33 marsh: all true, but still concerned about interaction with XMLP. Haven't seen a lot of speed from XMLP. 21:57:54 marsh: Don't expect them to speed up significantly. Dependency worries me. 21:58:10 marsh: Thought dave o's proposal had merit. 21:58:20 q+ 21:58:44 daveo: If we don't refer to them directly, need insulation. That's the joy of having some sort of MEP. Think we can get away with, say, uber-MEP proposal. 21:58:54 daveo: as backup plan. 21:59:22 q+ 21:59:29 daveo: Can't test MEP doc on its own anyway. Need binding to test. 22:00:18 q? 22:00:25 ack dhull 22:00:28 ack uyal 22:00:29 mnot: at high level, would have to leave note of forward ref in that document, change it during last call. DaveO is saying if XMLP doesn't come through, change forward reference to point to our stuff. Right? 22:00:33 daveo: right. 22:01:15 umit: Not opposed to writing wire requirement. Sneaky to request this for SOAP 1.1. Can do this for SOAP 1.2, have agreement. Shouldn't define MEP for 1.1 22:01:38 daveo: Nice thing about such a MEP is it gives us that abstraction. Putting it on SOAP 1.1 would not change wire behavior. 22:02:07 umit: People in my company would be upset. Don't expand scope and change SOAP 1.1. 22:02:22 daveo: How to handle non-anonymous? 22:02:40 umit: already done for SOAP 1.1 in my proposal. Let's not repeat work. 22:02:48 q? 22:02:51 ack anish 22:03:00 mnot: Think we have way to move forward process-wise. Will talk to team. Let's re-focus on this. 22:03:23 anish: Want to understand schedule. First go to last call, hope XMLP is in LC before we're in CR. 22:04:13 anish: Deliverables in XMLP charter mention LC for one-way MEP in March 2006. 22:04:26 http://www.w3.org/2005/07/XML-Protocol-Charter.html#deliverables 22:04:42 anish: http://www.w3.org/2005/07/XML-Protocol-Charter.html#deliverables 22:05:48 anish: could do what DaveO suggests: put in an abstract MEP for leeway, but do we need uber-MEP or just generic SOAP one-way? 22:05:59 mnot: Already fairly abstract. 22:06:33 mnot: Other discussion of i059: disposition of section 3.1.2 22:06:45 http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/0021 22:06:55 TOPIC: Other discussion of i059: disposition of section 3.1.2 (http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/0021) 22:07:39 mnot: Marc didn't think majority of text belonged in WSDL binding doc. Some agreement. Item 5 was similar: should we reference WSI BP? 22:08:24 mnot: 3 or 4 options: 1) leave in WSDL doc. 2) CR issue against SOAP doc (looks "substantial") 3) Separate doc, publish as note, reference that 4) Some other home, not sure where 22:08:33 mnot: (maybe XMLP) 22:08:57 umit: Do we have another chance to move CR back to LC by including this text? 22:09:10 mnot: That was option 2. Would move SOAP doc back to WD. 22:09:16 Glen: Does it have to? 22:09:25 mnot: It's a substantial change. 22:09:33 anish: Can go to LC instead of WD. 22:09:42 mnot: With permission of director. 22:09:48 glend: WSDL did this 22:09:59 umit: Wouldn't option 3 put us in same boat? 22:10:20 umit: Similar with media types in WSDL 22:11:06 mnot: different situation. (2) means all of SOAP doc back to WD, (3) separate doc, continue on present path with WSDL doc, no change to SOAP doc (stays in CR), reference from WSDL doc 22:11:25 umit: Have heard concerns about referencing note not in rec track. 22:11:58 mnot: It's a note about SOAP 1.1. Would be optional section in WSDL doc as well (can't be mandatory). Can't imagine w3c displeased with pushing SOAP 1.1 stuff into note. 22:12:11 umit: Does this mean we don't have to deal with 1.2 22:12:26 mnot: I was talking about 1.1. Are you talking about 1.2 as well? 22:12:50 anish: Marc's objection is that we're talking about a SOAP binding. Not a problem in the 1.2 case. 22:13:17 mnot: We're talking about extending a 1.1 binding, doesn't really belong here. 22:13:33 umit: don't have to solve 1.2 at all, SOAP 1.1 becomes note, we're done. 22:14:01 mnot: Don't have to come up with binding for 1.2 22:14:24 s/SOAP1.1/SOAP 1.1 behaviour we define/ 22:14:40 anish: Some form of section 3.1.3, 3.1.2 as note. 22:15:12 mnot: What would reference look like? Normative, otherwise 22:15:19 anish: Normative for 1.1 22:15:41 anish: WSDL binding would have SOAP 1.1, normatively points to note, 1.2 points to XMLP 22:15:57 katy: What sort of process does note go through? 22:16:03 mnot: Relatively lightwieght 22:16:07 umit: Depends 22:16:15 mnot: can add more requirements 22:16:21 katy: still normative? 22:16:31 mnot: stable reference, but not a W3C REC 22:16:55 mnot: Normative doc about 1.1 would be strange, as 1.1 is not a REC 22:17:11 umit: referencing media types normatively was not liked by W3C. 22:17:18 -Tom_Rutt 22:17:55 mnot: W3C not here today, but my understanding is that this won't be as problematic, as it's in an optional section about SOAP 1.1. Don't have to implement it (can just implement 1.2 stuff). 1.1 itself is just a note. 22:18:08 +Tom_Rutt 22:18:14 -Tom_Rutt 22:18:18 mnot: WIll have to talk to team about this in any case, as it's publishing another document. 22:18:39 mnot: assuming that process will work, are people amenable on this subissue? 22:18:44 omnes: silence 22:18:53 tony: Not ideal but will do. 22:18:58 Glen: pragmatic solution 22:19:23 mnot: useful outside WSA? Would be argument for separate doc. 22:19:28 +Tom_Rutt 22:19:33 umit: Why would (3) be better than (2) 22:20:07 mnot: don't want to go back to WD on SOAP binding absent a real technical problem. This is basically an esthetic issue, right. 22:20:13 umit: Marc might disagree. 22:20:59 glen: also not sure. Making semantics of WSA engaged crisper for SOAP. As it happens we do this by marking WSDL, but we're really dealing with SOAP semantics. References murky "application" idea, which is WSDL. 22:21:01 q+ to say that if we decide to go with option 2, we can still take the Note to LC 22:21:04 mnot: not sure 22:21:37 katy: Could we go for (2) and treat it as an extension and not go back to WD? 22:21:46 mnot: Does anyone think this isn't a substantial change? 22:22:00 katy: not suggesting it's not substantial, but have we considered the possibility 22:22:23 glen: interesting to explore. Will this really change implementor's behavior? Outside of WSDL, maybe not. 22:22:37 -MarkN 22:22:41 mnot: That's not what process says. Would it change implementor's experience in reasonable case. 22:22:55 katy: Key question is would impls still interoperate? 22:23:18 +MarkN 22:24:05 katy: If no, would have to consider going back. 22:24:37 mnot: Can't make up our own rules. Rule is will it change implementor's experience. Actually, does it pass giggle test? Wil lbe hard. 22:24:40 marsh: agree 22:25:12 anish: We're talking about 202 coming back in SOAP 1.1. How many impls will barf. From XMLP call, not many. 22:25:38 anish: So practically, many impls already handle what we're proposing. 22:26:47 mnot: need to close i059. Have umit's proposal, various deltas. Addendum from dhull, deltas to wording to fit with rest of doc. Is this enough info to decide on closing i059. Not in LC yet, so don't need exact final text (editor's discretion) 22:27:25 mnot: Could close i059. If there are issue, can revisit. 22:27:46 marsh: 3.1.2 (dhull) would go in WSDL spec? 22:27:49 mnot: Yes. 22:27:58 Marsh: so bailing on Marc's proposal? 22:28:06 mnot: No, that's the SOAP 1.1 stuff. 22:28:33 mnot: 1.1 section would reference external doc, 1.2 would reference upcoming XMLP. 22:28:37 marsh: NAK 22:29:10 -TonyC 22:29:14 marsh: Thought Marc wanted to push some material (including text from 3.1.2) into SOAP CR doc. 22:29:43 several: This was about SOAP 1.1/HTTP, not about SOAP 1.2 MEPs 22:30:29 mnot: What would make you more comfortable? 22:30:51 marsh: Heard displeasure from Marc, not sure how this is to be resolved. Do we expect him to be happy with this? 22:31:15 mnot: Marc mainly wanted HTTP binding stuff out of WSDL doc. 22:31:37 daveO: Share some of Marc's concerns about binding description in WSDL extension. 22:31:39 Glen: +1 22:32:16 mnot: Will split off this as separate issue, need to talk to team. Late bind decision of just where this gets pushed to. 22:32:36 s/this/section 3.1.2 22:32:55 TonyR: Seems OK 22:33:18 anish2 has joined #ws-addr 22:33:29 q? 22:33:31 mnot: Adding Umit as editor of WSDL doc. So editor's discretion effectively means Umits. 22:34:19 mnot: Objections to closing i059 as WD issue with proposal 4 (3 + addendum) + editors' discretion? 22:35:09 anish: Question: If we have issues (say from WSRX) then we open new issue and go from there? 22:35:15 mnot: Yes. 22:35:46 mnot: Can raise informal issues for interpretation, new info (e.g. from external group) can raise new issues. 22:36:05 mnot: If no info but people just don't like this in a couple of weeks, alea iacta est. 22:36:41 umit: As person who would integrate this, will have to crisply define what we mean by one-way MEP before we're done. 22:37:09 katy: Separate decision just what one-way MEP means. 22:37:22 katy: Voting on umit's text + addendum 22:37:32 glenD: not comfortable with addendum. 22:37:40 mnot: comfortable with substance. 22:38:10 glenD: uncomfortable with switching MEPs on the fly. Relates to old async TF discussion, current XMLP discussion. 22:39:15 glenD: Clearly there will be a decision made whether there will be a new connection or not. Might be mU fault, application-level decision. Question as to whether to model this as one MEP that's optional response, or whether it's different MEPs depending on case. 22:39:55 GlenD: Adding this text takes a position, that you don't know SOAP MEP until application does its work, as opposed to you do know what SOAP MEP you're using. Like the latter better. 22:40:16 GlenD: This approach seems to limit usefulness of abstraction. 22:40:53 DaveO: Don't understand distinction being made. I've tried to separate out "either there is a response or not". 22:41:53 Daveo: There will be some decision somewhere as to whether request is required, allowed, not allowed. Can be set many different places. Anything in stack that says that you might get a response, you should expect one. 22:42:05 DaveO: Then there is the actuality of whether a response happens on the wire. 22:42:43 DaveO: So distinction between one MEP and two possible MEPs is an abstraction that makes no difference on wire. Request-optional-response may be simple, but doesn't make huge difference. 22:42:52 mnot: So can we go ahead? 22:43:13 daveo: Would like to see actual combined text, but seems reasonable to me to do binding by reference, nto value. 22:43:14 q? 22:44:10 Glen: Agre that impls won't change, we're deciding on modeling/framing. Just seems to me clearer from abstraction POV to say "Here is an MEP that mirrors HTTP MEP, and that's your MEP". Of course optionality is there somewhere. 22:44:38 Glen: Seems less clear to say "binding can be request-response or one-way and won't know until runtime". 22:44:46 q+ 22:44:57 daveo: Flexible MEP is just playing a shell game, if it can go either way. 22:45:15 Glen: HTTP gives value: either there is a body or not, some status code, etc., this is useful. 22:45:46 daveo: yes but ... at SOAP level, the notion of a MEP not telling you there will be a response has no value. 22:45:57 ack uyal 22:46:56 umit: Concerned that we will not be able to incorporate SOAP 1.2 text that people will be happy about. Two choices: 1) Considering marc's concerrn, could we close i059 and open new issues and decide whether WD issues or LC issues? 22:47:02 q+ 22:47:27 q+ 22:48:07 umit: There will definitely be issues with 3.1.3. 2) Is close i059 and have LC issues with it 22:49:06 q? 22:49:18 daveo: Can either work on text prior to LC or incorporate and have LC comments. LC means we think we're done, so shouldn't go to LC until we think we're done. Prefer to have text we're really comforatable with and go to a real LC. 22:50:02 umit: This particular issue is in front of XMLP. Pessimistic about resolving SOAP 1.2 text comfortably. 22:50:43 ack dhull 22:51:53 -TonyR 22:51:57 TonyR has left #ws-addr 22:52:09 TRutt has joined #ws-addr 22:52:11 TonyR has joined #ws-addr 22:52:29 TonyR has left #ws-addr 22:53:22 yes 22:53:38 q- 22:53:41 -swinkler 22:53:51 ack anish 22:53:51 anish, you wanted to say that if we decide to go with option 2, we can still take the Note to LC 22:54:09 dhull: May be able to re-word 3.1.3 proposal a bit more abstractly, to capture that we need a decision point somewhere, without taking position on modeling decision. 22:54:26 +1 22:54:28 anish: Could we split i059 into SOAP 1.1, SOAP 2.2 22:54:33 katy: +1 22:54:45 mnot: A bit tricky, but we can see. 22:55:15 mnot: Straw poll. Comfortable with closing i059 as currently proposed, with friendly amendment to describe both possible models in 3.1.3 22:55:48 marsh: comfortable 22:56:07 bob: comfortable with seeing some text on that. 22:56:15 mnot: can still raise issues 22:56:24 comfortable, but would like rights to question words 22:56:38 daveo: uncomfortable 22:56:43 uncomfortable 22:56:53 glen: want to see whole thing before going forth 22:57:02 marsh: Had meant to say "uncomfortable" 22:57:06 I would like to see the words before closing 22:57:12 same here 22:57:57 daveo: I could put together a new combined proposal 22:58:18 several: 1.2 text main source of discomfort. 22:58:29 agree 1.2 is my main discomfort 22:58:30 +1 22:58:58 +1 to close 59 with 1.1 text as is 23:00:14 various: confusion as to just what is being closed 23:00:32 -Liam? 23:00:40 umit: Can address 1.2 separately 23:01:24 mnot: any objection to closing i059 with proposal 3 + opening 2 new issues 23:01:41 daveo: very uncomfortable with closing this way. Can live with it. 23:01:57 daveo: what have we gained? 23:02:11 umit: using addressing, anonymous markup goes into text. 23:02:24 marsh: still uncomfortable with "prohibited" value 23:02:36 -??P18 23:03:09 marsh: Don't think it's the best way to accomplish its purpose, but don't have counter-proposal, yet. Would like to have option to put forth counterproposal later. 23:03:42 mnot: Will split into three issues, expect to close first soon. Chunking up is only way forward. 23:04:08 ACTION: Dave Hull and Dave Orchard will re-work SOAP 1.2 proposal to address concerns raised today. 23:04:15 -Dave_Orchard 23:04:17 -Gilbert_Pilz.a 23:04:24 -Anish 23:04:25 -Jonathan_Marsh 23:04:25 mnot: Any response on XMPL issue 39? 23:04:25 -MarkN 23:04:26 -??P20 23:04:27 -Bob_Freund 23:04:28 -??P25 23:04:28 -Nilo_Mitra 23:04:29 omnes: silence 23:04:29 -Tom_Rutt 23:04:31 -Paul_Knight 23:04:33 -Vikas_Deolaliker 23:04:35 -Prasad_Yendluri 23:04:37 -Umit_Yalcinalp 23:04:39 -Pete_Wenzel 23:04:40 vinoski has left #ws-addr 23:04:41 -Mark_Peel/Katy_Warr 23:04:43 -[IPcaller] 23:04:47 -David_Illsley 23:07:13 ACTION: David Orchard to revise David Hull's proposal WRT SOAP 1.2. 23:07:30 rrsagent, delete action 4 23:07:30 I'm logging. I don't understand 'delete action 4', mnot. Try /msg RRSAgent help 23:08:07 rrsagent, make logs public 23:08:14 rrsagent, generate minutes 23:08:15 I have made the request to generate http://www.w3.org/2005/12/12-ws-addr-minutes.html mnot 23:08:39 bob has left #ws-addr 23:10:11 TRutt has left #ws-addr 23:17:12 -??P10