IRC log of ws-addr on 2005-12-12

Timestamps are in UTC.

20:35:23 [RRSAgent]
RRSAgent has joined #ws-addr
20:35:23 [RRSAgent]
logging to
20:35:26 [mnot]
zakim, this will be WS_ADDR
20:35:26 [Zakim]
ok, mnot; I see WS_AddrWG()4:00PM scheduled to start in 25 minutes
20:35:38 [mnot]
Meeting: Web Services Addressing Working Group Teleconference
20:35:42 [mnot]
Chair: Mark Nottingham
20:35:55 [mnot]
20:41:50 [David_Illsley]
David_Illsley has joined #ws-addr
20:42:27 [Jonathan_Marsh]
Jonathan_Marsh has joined #ws-addr
20:47:35 [TonyR]
TonyR has joined #ws-addr
20:49:48 [TonyC]
TonyC has joined #ws-addr
20:52:03 [PaulKnight]
PaulKnight has joined #ws-addr
20:53:17 [TRutt]
TRutt has joined #ws-addr
20:56:35 [prasad]
prasad has joined #ws-Addr
20:57:06 [Nilo]
Nilo has joined #ws-addr
20:58:35 [Zakim]
WS_AddrWG()4:00PM has now started
20:58:42 [Zakim]
20:58:49 [Katy]
Katy has joined #ws-addr
20:59:09 [Bozhong]
Bozhong has joined #ws-addr
20:59:30 [Zakim]
20:59:35 [Zakim]
20:59:44 [bob]
bob has joined #ws-addr
21:00:23 [Zakim]
21:00:36 [Zakim]
21:00:50 [Zakim]
21:01:07 [Zakim]
21:01:23 [Zakim]
21:01:26 [Zakim]
21:01:31 [Zakim]
21:01:34 [Zakim]
21:01:36 [Zakim]
21:01:49 [Bozhong]
that's bozhong
21:01:56 [Zakim]
21:01:57 [Zakim]
21:02:21 [Zakim]
21:03:19 [Zakim]
21:03:21 [dhull]
dhull has joined #ws-addr
21:03:34 [Zakim]
21:03:42 [Zakim]
21:04:06 [vinoski]
vinoski has joined #ws-addr
21:04:06 [Zakim]
21:04:16 [TonyR]
zakim, ??p16 is me
21:04:16 [Zakim]
+TonyR; got it
21:04:39 [Zakim]
21:04:46 [uyalcina]
uyalcina has joined #ws-addr
21:04:54 [anish]
anish has joined #ws-addr
21:04:58 [Zakim]
21:05:08 [Zakim]
21:06:24 [swinkler]
swinkler has joined #ws-addr
21:08:38 [Zakim]
21:08:48 [dhull]
scribe: dhull
21:09:17 [Zakim]
21:09:32 [swinkler]
Zakim, Steve_Winkler is me
21:09:32 [Zakim]
+swinkler; got it
21:10:14 [Marsh]
Marsh has joined #ws-addr
21:10:26 [dhull]
Action: Approved minutes 11/28
21:10:43 [dhull]
ACTION: Approved minutes 12/5
21:11:34 [Zakim]
21:12:26 [dhull]
TOPIC: testing
21:13:17 [dhull]
mikep: Working toward public endpoints prior to F2F, some preliminary interop before F2F, aiming to satisfy requirements in Jan
21:13:52 [dhull]
dillseley: Planning on endpoint in next couple of weeks
21:14:16 [dhull]
markn: WSO2 is planning on joining for testing
21:14:50 [dhull]
TOPIC: Issue 66
21:15:10 [dhull]
mnot: Owner will be Marsh
21:16:06 [dhull]
mnot: No calls between next week and Jan 9
21:16:13 [dhull]
TOPIC: I 059
21:16:35 [dhull]
mnot: Understanding is there are two general areas of discussion
21:16:46 [dhull]
mnot: 1) dhull proposal for SOAP 1.2
21:16:54 [dhull]
mnot: 2) disposition of SOAP 1.1
21:17:21 [dhull]
mnot: 1 is proposal 4. Fulfilling the need to incorporate SOAP 1.2 into proposal.
21:17:53 [Marsh]
Dhull: Walks through the proposal
21:18:10 [Marsh]
... early part of section 3 is what markup we use and how it fits into the WSDL model.
21:18:26 [Marsh]
... section 3.1.2 talks about a modification to the HTTP SOAP 1.1 binding.
21:18:44 [Marsh]
... this proposal talks about how to map the WSDL 2.0 meps to the SOAP 1.2 adjuncts
21:18:56 [Marsh]
... assumes there will be a one-way mep produced at some point.
21:19:13 [Marsh]
... all this is is three short rules.
21:19:15 [anish]
21:19:38 [Marsh]
... In response to some feedback from MarcH I rearranged this slightly.
21:20:12 [Marsh]
... 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:16 [Zakim]
21:20:52 [vikas]
vikas has joined #ws-addr
21:20:58 [Marsh]
... You either have a SOAP req-resp happening, in which case we bind to the SOAP req-resp mep
21:21:15 [Marsh]
... Otherwise you have to bind to two one-ways.
21:21:36 [Marsh]
... You have to conform to the one-way in each direction.
21:23:11 [Marsh]
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 [Marsh]
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]
gpilz has joined #ws-addr
21:24:33 [Marsh]
... Instead you talk about the behavior keying off of anonymous. It's a cue to use the req-resp mep.
21:24:51 [Marsh]
Umit: That's right! But doesn't come across in this write-up.
21:25:23 [TonyC]
TonyC has joined #ws-addr
21:25:31 [Marsh]
... Write-up starts with anonymous markup, behavior follows.
21:25:34 [anish]
q+ to ask if "SOAP one-way" is used generically
21:25:50 [Marsh]
DHull: I think that's all implicit, fine with making it more explicit.
21:26:31 [Marsh]
... When WS-A is engaged, with anonynous="required", you always fall through to, use req-resp mep.
21:26:43 [Marsh]
... The chain determines this but it might not be obvious at first.
21:27:38 [Marsh]
Umit: Write it so that instead of a separate section you could follow the same logic for what anonymous='required' means.
21:28:02 [Marsh]
... for SOAP 1.1 and 1.2.
21:28:02 [Marsh]
DHull: You get the same logic in either case.
21:28:16 [Marsh]
Umit: The one-way mep doesn't exist today...
21:29:31 [Marsh]
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 [Marsh]
Umit: Right now these two write-ups don't hang together well.
21:30:20 [Marsh]
... If I have anonymous constraints in the WSDL, how does that work with this? It's impossible to figure out.
21:30:32 [Marsh]
DHull: Not impossible, just walk through the rules.
21:30:32 [jeffm]
jeffm has joined #ws-addr
21:30:44 [Marsh]
Umit: If I don't use this I can't use SOAP req-resp MEP, right?
21:32:10 [Marsh]
DHull: Would you consider these problems as sturctural or editorial>
21:32:14 [Marsh]
Umit: not sure
21:32:14 [mnot]
ack anish
21:32:14 [Zakim]
anish, you wanted to ask if "SOAP one-way" is used generically
21:32:35 [Marsh]
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 [Marsh]
... What did you mean by one-way MEP? Does it include the new one the XMLP WG may define?
21:34:23 [uyalcina]
21:34:33 [Zakim]
21:34:33 [Marsh]
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 [Zakim]
21:34:44 [Zakim]
21:34:53 [Marsh]
21:35:20 [Zakim]
21:35:39 [Marsh]
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 [Marsh]
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 [Marsh]
... One way of modelling that is considering the poll and the response as an instance of the Response MEP.
21:36:57 [Marsh]
... The other would be to say the Response MEP can be considered a one-way.
21:37:23 [Marsh]
Anish: I was thinking along those lines when the requester is behind a firewall a callback can happen.
21:37:27 [mnot]
21:37:41 [mnot]
ack uyal
21:38:16 [Marsh]
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 [anish]
s/callback can happen/callback cannot happen/
21:38:28 [Marsh]
... You say you must comply with the SOAP one-way MEP - which isn't defined.
21:38:43 [Marsh]
... So what can you do here?
21:39:06 [Marsh]
DHull: Assume for our testing purposes the one-way over HTTP is a POST and a 202 return.
21:39:15 [Marsh]
MNot: Concerned about testing it?
21:39:17 [Marsh]
Umit: Yes.
21:39:29 [Marsh]
DHull: I rewrote this on the assumption that the one-way existed.
21:39:41 [Marsh]
... Screened off the elephant in the room.
21:39:48 [Zakim]
+ +1.619.291.aaaa - is perhaps Liam?
21:40:20 [Marsh]
... 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 [Marsh]
... One mep in in-only, robust-in-only when there is no fault.
21:41:03 [Marsh]
MNot: How complete is this? Are folks uncomfortable with the general direction?
21:42:17 [Marsh]
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 [Marsh]
DHull: Recognize this is useful.
21:43:10 [Marsh]
... 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 [gpilz]
21:43:31 [Marsh]
... We'd have to make a call on whether the anonymous was used for an unexpected purpose.
21:44:02 [Marsh]
... Think I'd lean towards considering that case as a req-resp.
21:44:11 [uyalcina]
s/soap body/empty soap body/
21:44:34 [gpilz]
21:44:40 [Marsh]
MNot: We're in a place where we need to coordinate with XMLP.
21:44:52 [gdaniels]
gdaniels has joined #ws-addr
21:44:54 [Marsh]
... How close are we to going to last call?
21:45:07 [Zakim]
21:45:28 [dhull]
21:45:39 [Marsh]
... 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 [uyalcina]
21:45:57 [Marsh]
DHull: I'll gladly take an action to look carefully at 3.1.3 better in line with 3.1.2.
21:46:26 [Marsh]
... 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 [Marsh]
MNot: We have a dependency on XMLP. We'd have to note that in the document.
21:46:58 [mnot]
21:47:05 [mnot]
ack dhull uyal
21:47:17 [mnot]
ack dhull uyal
21:47:17 [mnot]
ack dhull
21:47:17 [mnot]
ack uyal
21:47:31 [Marsh]
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 [Marsh]
... I don't have a good sense of the XMLP timeline.
21:47:56 [Marsh]
MNot: We're already dependent upon WSDL doc on WSDL 2.0.
21:48:23 [Jonathan_Marsh]
Jonathan_Marsh has joined #ws-addr
21:48:40 [dhull]
scribe: dhull
21:48:53 [Zakim]
21:49:13 [dhull]
mnot: take umits point about divide and conquer, but would be concerned about needing to wait
21:49:22 [andreas]
andreas has joined #ws-addr
21:49:32 [dhull]
umit: WSDL 2.0 is way ahead of XMLP, so XMLP dependency less of a concern
21:49:47 [dhull]
mnot: Even if we go to LC now or soon, there will still be time
21:50:04 [dhull]
mnot: XMPL LC Feb-Mar would not hold us up.
21:50:14 [dhull]
anish: hard to say
21:50:25 [TRutt]
TRutt has joined #ws-addr
21:50:26 [dhull]
anish: XMLP will be F2F at plenary
21:51:01 [dhull]
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 [dhull]
mnot: Publishing this as LC would give them something to shoot for.
21:51:50 [dhull]
anish: At least we get the rest of this stuff out for comment.
21:52:26 [dhull]
mnot: Can ask if editors feel comfortable (after 66) folding in these proposals.
21:52:41 [dhull]
marsh: Is this absolutely fundamental? What if XMLP doesn't converge?
21:52:58 [dhull]
marsh: Can we insulate by referring to "one-way" generically
21:53:06 [dhull]
mnot: could publish but could we test?
21:53:07 [mnot]
21:53:12 [dhull]
21:53:42 [dhull]
dhull: could we note assumptions made for testing?
21:54:18 [dhull]
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 [dhull]
marsh: worry is that people would interop to this and XMLP would contradict this.
21:54:49 [dhull]
mnot: if we can interop and XMLP doesn't say anything, what's the problem?
21:55:44 [dhull]
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 [dhull]
daveo: Then say that actual binding has to be equivalent. We get interop.
21:56:17 [dhull]
dhull: basically what non-normative note in original proposal was aimed at.
21:57:11 [dhull]
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 [dhull]
marsh: all true, but still concerned about interaction with XMLP. Haven't seen a lot of speed from XMLP.
21:57:54 [dhull]
marsh: Don't expect them to speed up significantly. Dependency worries me.
21:58:10 [dhull]
marsh: Thought dave o's proposal had merit.
21:58:20 [uyalcina]
21:58:44 [dhull]
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 [dhull]
daveo: as backup plan.
21:59:22 [anish]
21:59:29 [dhull]
daveo: Can't test MEP doc on its own anyway. Need binding to test.
22:00:18 [mnot]
22:00:25 [mnot]
ack dhull
22:00:28 [mnot]
ack uyal
22:00:29 [dhull]
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 [dhull]
daveo: right.
22:01:15 [dhull]
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 [dhull]
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 [dhull]
umit: People in my company would be upset. Don't expand scope and change SOAP 1.1.
22:02:22 [dhull]
daveo: How to handle non-anonymous?
22:02:40 [dhull]
umit: already done for SOAP 1.1 in my proposal. Let's not repeat work.
22:02:48 [mnot]
22:02:51 [mnot]
ack anish
22:03:00 [dhull]
mnot: Think we have way to move forward process-wise. Will talk to team. Let's re-focus on this.
22:03:23 [dhull]
anish: Want to understand schedule. First go to last call, hope XMLP is in LC before we're in CR.
22:04:13 [dhull]
anish: Deliverables in XMLP charter mention LC for one-way MEP in March 2006.
22:04:26 [anish]
22:04:42 [dhull]
22:05:48 [dhull]
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 [dhull]
mnot: Already fairly abstract.
22:06:33 [dhull]
mnot: Other discussion of i059: disposition of section 3.1.2
22:06:45 [mnot]
22:06:55 [dhull]
TOPIC: Other discussion of i059: disposition of section 3.1.2 (
22:07:39 [dhull]
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 [dhull]
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 [dhull]
mnot: (maybe XMLP)
22:08:57 [dhull]
umit: Do we have another chance to move CR back to LC by including this text?
22:09:10 [dhull]
mnot: That was option 2. Would move SOAP doc back to WD.
22:09:16 [dhull]
Glen: Does it have to?
22:09:25 [dhull]
mnot: It's a substantial change.
22:09:33 [dhull]
anish: Can go to LC instead of WD.
22:09:42 [dhull]
mnot: With permission of director.
22:09:48 [dhull]
glend: WSDL did this
22:09:59 [dhull]
umit: Wouldn't option 3 put us in same boat?
22:10:20 [dhull]
umit: Similar with media types in WSDL
22:11:06 [dhull]
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 [dhull]
umit: Have heard concerns about referencing note not in rec track.
22:11:58 [dhull]
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 [dhull]
umit: Does this mean we don't have to deal with 1.2
22:12:26 [dhull]
mnot: I was talking about 1.1. Are you talking about 1.2 as well?
22:12:50 [dhull]
anish: Marc's objection is that we're talking about a SOAP binding. Not a problem in the 1.2 case.
22:13:17 [dhull]
mnot: We're talking about extending a 1.1 binding, doesn't really belong here.
22:13:33 [dhull]
umit: don't have to solve 1.2 at all, SOAP 1.1 becomes note, we're done.
22:14:01 [dhull]
mnot: Don't have to come up with binding for 1.2
22:14:24 [uyalcina]
s/SOAP1.1/SOAP 1.1 behaviour we define/
22:14:40 [dhull]
anish: Some form of section 3.1.3, 3.1.2 as note.
22:15:12 [dhull]
mnot: What would reference look like? Normative, otherwise
22:15:19 [dhull]
anish: Normative for 1.1
22:15:41 [dhull]
anish: WSDL binding would have SOAP 1.1, normatively points to note, 1.2 points to XMLP
22:15:57 [dhull]
katy: What sort of process does note go through?
22:16:03 [dhull]
mnot: Relatively lightwieght
22:16:07 [dhull]
umit: Depends
22:16:15 [dhull]
mnot: can add more requirements
22:16:21 [dhull]
katy: still normative?
22:16:31 [dhull]
mnot: stable reference, but not a W3C REC
22:16:55 [dhull]
mnot: Normative doc about 1.1 would be strange, as 1.1 is not a REC
22:17:11 [dhull]
umit: referencing media types normatively was not liked by W3C.
22:17:18 [Zakim]
22:17:55 [dhull]
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 [Zakim]
22:18:14 [Zakim]
22:18:18 [dhull]
mnot: WIll have to talk to team about this in any case, as it's publishing another document.
22:18:39 [dhull]
mnot: assuming that process will work, are people amenable on this subissue?
22:18:44 [dhull]
omnes: silence
22:18:53 [dhull]
tony: Not ideal but will do.
22:18:58 [dhull]
Glen: pragmatic solution
22:19:23 [dhull]
mnot: useful outside WSA? Would be argument for separate doc.
22:19:28 [Zakim]
22:19:33 [dhull]
umit: Why would (3) be better than (2)
22:20:07 [dhull]
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 [dhull]
umit: Marc might disagree.
22:20:59 [dhull]
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 [anish]
q+ to say that if we decide to go with option 2, we can still take the Note to LC
22:21:04 [dhull]
mnot: not sure
22:21:37 [dhull]
katy: Could we go for (2) and treat it as an extension and not go back to WD?
22:21:46 [dhull]
mnot: Does anyone think this isn't a substantial change?
22:22:00 [dhull]
katy: not suggesting it's not substantial, but have we considered the possibility
22:22:23 [dhull]
glen: interesting to explore. Will this really change implementor's behavior? Outside of WSDL, maybe not.
22:22:37 [Zakim]
22:22:41 [dhull]
mnot: That's not what process says. Would it change implementor's experience in reasonable case.
22:22:55 [dhull]
katy: Key question is would impls still interoperate?
22:23:18 [Zakim]
22:24:05 [dhull]
katy: If no, would have to consider going back.
22:24:37 [dhull]
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 [dhull]
marsh: agree
22:25:12 [dhull]
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 [dhull]
anish: So practically, many impls already handle what we're proposing.
22:26:47 [dhull]
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 [dhull]
mnot: Could close i059. If there are issue, can revisit.
22:27:46 [dhull]
marsh: 3.1.2 (dhull) would go in WSDL spec?
22:27:49 [dhull]
mnot: Yes.
22:27:58 [dhull]
Marsh: so bailing on Marc's proposal?
22:28:06 [dhull]
mnot: No, that's the SOAP 1.1 stuff.
22:28:33 [dhull]
mnot: 1.1 section would reference external doc, 1.2 would reference upcoming XMLP.
22:28:37 [dhull]
marsh: NAK
22:29:10 [Zakim]
22:29:14 [dhull]
marsh: Thought Marc wanted to push some material (including text from 3.1.2) into SOAP CR doc.
22:29:43 [dhull]
several: This was about SOAP 1.1/HTTP, not about SOAP 1.2 MEPs
22:30:29 [dhull]
mnot: What would make you more comfortable?
22:30:51 [dhull]
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 [dhull]
mnot: Marc mainly wanted HTTP binding stuff out of WSDL doc.
22:31:37 [dhull]
daveO: Share some of Marc's concerns about binding description in WSDL extension.
22:31:39 [dhull]
Glen: +1
22:32:16 [dhull]
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 [uyalcina]
s/this/section 3.1.2
22:32:55 [dhull]
TonyR: Seems OK
22:33:18 [anish2]
anish2 has joined #ws-addr
22:33:29 [anish2]
22:33:31 [dhull]
mnot: Adding Umit as editor of WSDL doc. So editor's discretion effectively means Umits.
22:34:19 [dhull]
mnot: Objections to closing i059 as WD issue with proposal 4 (3 + addendum) + editors' discretion?
22:35:09 [dhull]
anish: Question: If we have issues (say from WSRX) then we open new issue and go from there?
22:35:15 [dhull]
mnot: Yes.
22:35:46 [dhull]
mnot: Can raise informal issues for interpretation, new info (e.g. from external group) can raise new issues.
22:36:05 [dhull]
mnot: If no info but people just don't like this in a couple of weeks, alea iacta est.
22:36:41 [dhull]
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 [dhull]
katy: Separate decision just what one-way MEP means.
22:37:22 [dhull]
katy: Voting on umit's text + addendum
22:37:32 [dhull]
glenD: not comfortable with addendum.
22:37:40 [dhull]
mnot: comfortable with substance.
22:38:10 [dhull]
glenD: uncomfortable with switching MEPs on the fly. Relates to old async TF discussion, current XMLP discussion.
22:39:15 [dhull]
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 [dhull]
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 [dhull]
GlenD: This approach seems to limit usefulness of abstraction.
22:40:53 [dhull]
DaveO: Don't understand distinction being made. I've tried to separate out "either there is a response or not".
22:41:53 [dhull]
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 [dhull]
DaveO: Then there is the actuality of whether a response happens on the wire.
22:42:43 [dhull]
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 [dhull]
mnot: So can we go ahead?
22:43:13 [dhull]
daveo: Would like to see actual combined text, but seems reasonable to me to do binding by reference, nto value.
22:43:14 [mnot]
22:44:10 [dhull]
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 [dhull]
Glen: Seems less clear to say "binding can be request-response or one-way and won't know until runtime".
22:44:46 [uyalcina]
22:44:57 [dhull]
daveo: Flexible MEP is just playing a shell game, if it can go either way.
22:45:15 [dhull]
Glen: HTTP gives value: either there is a body or not, some status code, etc., this is useful.
22:45:46 [dhull]
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 [mnot]
ack uyal
22:46:56 [dhull]
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 [dhull]
22:47:27 [Katy]
22:48:07 [dhull]
umit: There will definitely be issues with 3.1.3. 2) Is close i059 and have LC issues with it
22:49:06 [mnot]
22:49:18 [dhull]
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 [dhull]
umit: This particular issue is in front of XMLP. Pessimistic about resolving SOAP 1.2 text comfortably.
22:50:43 [mnot]
ack dhull
22:51:53 [Zakim]
22:51:57 [TonyR]
TonyR has left #ws-addr
22:52:09 [TRutt]
TRutt has joined #ws-addr
22:52:11 [TonyR]
TonyR has joined #ws-addr
22:52:29 [TonyR]
TonyR has left #ws-addr
22:53:22 [bob]
22:53:38 [Katy]
22:53:41 [Zakim]
22:53:51 [mnot]
ack anish
22:53:51 [Zakim]
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]
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 [uyalcina]
22:54:28 [dhull]
anish: Could we split i059 into SOAP 1.1, SOAP 2.2
22:54:33 [dhull]
katy: +1
22:54:45 [dhull]
mnot: A bit tricky, but we can see.
22:55:15 [dhull]
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 [dhull]
marsh: comfortable
22:56:07 [dhull]
bob: comfortable with seeing some text on that.
22:56:15 [dhull]
mnot: can still raise issues
22:56:24 [TRutt]
comfortable, but would like rights to question words
22:56:38 [dhull]
daveo: uncomfortable
22:56:43 [gpilz]
22:56:53 [dhull]
glen: want to see whole thing before going forth
22:57:02 [dhull]
marsh: Had meant to say "uncomfortable"
22:57:06 [TRutt]
I would like to see the words before closing
22:57:12 [Nilo]
same here
22:57:57 [dhull]
daveo: I could put together a new combined proposal
22:58:18 [dhull]
several: 1.2 text main source of discomfort.
22:58:29 [TRutt]
agree 1.2 is my main discomfort
22:58:30 [gdaniels]
22:58:58 [TRutt]
+1 to close 59 with 1.1 text as is
23:00:14 [dhull]
various: confusion as to just what is being closed
23:00:32 [Zakim]
23:00:40 [dhull]
umit: Can address 1.2 separately
23:01:24 [dhull]
mnot: any objection to closing i059 with proposal 3 + opening 2 new issues
23:01:41 [dhull]
daveo: very uncomfortable with closing this way. Can live with it.
23:01:57 [dhull]
daveo: what have we gained?
23:02:11 [dhull]
umit: using addressing, anonymous markup goes into text.
23:02:24 [dhull]
marsh: still uncomfortable with "prohibited" value
23:02:36 [Zakim]
23:03:09 [dhull]
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 [dhull]
mnot: Will split into three issues, expect to close first soon. Chunking up is only way forward.
23:04:08 [dhull]
ACTION: Dave Hull and Dave Orchard will re-work SOAP 1.2 proposal to address concerns raised today.
23:04:15 [Zakim]
23:04:17 [Zakim]
23:04:24 [Zakim]
23:04:25 [Zakim]
23:04:25 [dhull]
mnot: Any response on XMPL issue 39?
23:04:25 [Zakim]
23:04:26 [Zakim]
23:04:27 [Zakim]
23:04:28 [Zakim]
23:04:28 [Zakim]
23:04:29 [dhull]
omnes: silence
23:04:29 [Zakim]
23:04:31 [Zakim]
23:04:33 [Zakim]
23:04:35 [Zakim]
23:04:37 [Zakim]
23:04:39 [Zakim]
23:04:40 [vinoski]
vinoski has left #ws-addr
23:04:41 [Zakim]
23:04:43 [Zakim]
23:04:47 [Zakim]
23:07:13 [mnot]
ACTION: David Orchard to revise David Hull's proposal WRT SOAP 1.2.
23:07:30 [mnot]
rrsagent, delete action 4
23:07:30 [RRSAgent]
I'm logging. I don't understand 'delete action 4', mnot. Try /msg RRSAgent help
23:08:07 [mnot]
rrsagent, make logs public
23:08:14 [mnot]
rrsagent, generate minutes
23:08:15 [RRSAgent]
I have made the request to generate mnot
23:08:39 [bob]
bob has left #ws-addr
23:10:11 [TRutt]
TRutt has left #ws-addr
23:17:12 [Zakim]