See also: IRC log
<scribe> scribe: dhull
<scribe> ACTION: Approved minutes 11/28 [recorded in http://www.w3.org/2005/12/12-ws-addr-minutes.html#action01]
<scribe> ACTION: Approved minutes 12/5 [recorded in http://www.w3.org/2005/12/12-ws-addr-minutes.html#action02]
mikep: Working toward public endpoints prior to F2F, some preliminary interop before F2F, aiming to satisfy requirements in Jan
dillseley: Planning on endpoint in next couple of weeks
markn: WSO2 is planning on joining for testing
mnot: Owner will be Marsh
... No calls between next week and Jan 9
mnot: Understanding is there are
two general areas of discussion
... 1) dhull proposal for SOAP 1.2
... 2) disposition of SOAP 1.1
... 1 is proposal 4. Fulfilling the need to incorporate SOAP
1.2 into proposal.
<Marsh> Dhull: Walks through the proposal
<Marsh> ... early part of section 3 is what markup we use and how it fits into the WSDL model.
<Marsh> ... section 3.1.2 talks about a modification to the HTTP SOAP 1.1 binding.
<Marsh> ... this proposal talks about how to map the WSDL 2.0 meps to the SOAP 1.2 adjuncts
<Marsh> ... assumes there will be a one-way mep produced at some point.
<Marsh> ... all this is is three short rules.
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/att-0093/WSDL20SOAP12.html
<Marsh> ... In response to some feedback from MarcH I rearranged this slightly.
<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.
<Marsh> ... You either have a SOAP req-resp happening, in which case we bind to the SOAP req-resp mep
<Marsh> ... Otherwise you have to bind to two one-ways.
<Marsh> ... You have to conform to the one-way in each direction.
<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.
<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.
<Marsh> ... Instead you talk about the behavior keying off of anonymous. It's a cue to use the req-resp mep.
<Marsh> Umit: That's right! But doesn't come across in this write-up.
<Marsh> ... Write-up starts with anonymous markup, behavior follows.
<Marsh> DHull: I think that's all implicit, fine with making it more explicit.
<Marsh> ... When WS-A is engaged, with anonynous="required", you always fall through to 3.1.3.1, use req-resp mep.
<Marsh> ... The chain determines this but it might not be obvious at first.
<Marsh> Umit: Write it so that instead of a separate section you could follow the same logic for what anonymous='required' means.
<Marsh> ... for SOAP 1.1 and 1.2.
<Marsh> DHull: You get the same logic in either case.
<Marsh> Umit: The one-way mep doesn't exist today...
<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.
<Marsh> Umit: Right now these two write-ups don't hang together well.
<Marsh> ... If I have anonymous constraints in the WSDL, how does that work with this? It's impossible to figure out.
<Marsh> DHull: Not impossible, just walk through the rules.
<Marsh> Umit: If I don't use this I can't use SOAP req-resp MEP, right?
<Marsh> DHull: Would you consider these problems as sturctural or editorial>
<Marsh> Umit: not sure
<Zakim> anish, you wanted to ask if "SOAP one-way" is used generically
<Marsh> Anish: When you refer to the SOAP 1.2 req-resp MEP, you might want to use the URI for the MEP.
<Marsh> ... What did you mean by one-way MEP? Does it include the new one the XMLP WG may define?
<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.
<Marsh> Anish: You're talking about how an exchange can be realized with one or two MEPs. The SOAP Response MEP would be disallowed?
<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.
<Marsh> ... One way of modelling that is considering the poll and the response as an instance of the Response MEP.
<Marsh> ... The other would be to say the Response MEP can be considered a one-way.
<Marsh> Anish: I was thinking along those lines when the requester is behind a firewall a callback cannot happen.
<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.
<Marsh> ... You say you must comply with the SOAP one-way MEP - which isn't defined.
<Marsh> ... So what can you do here?
<Marsh> DHull: Assume for our testing purposes the one-way over HTTP is a POST and a 202 return.
<Marsh> MNot: Concerned about testing it?
<Marsh> Umit: Yes.
<Marsh> DHull: I rewrote this on the assumption that the one-way existed.
<Marsh> ... Screened off the elephant in the room.
<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.
<Marsh> ... One mep in in-only, robust-in-only when there is no fault.
<Marsh> MNot: How complete is this? Are folks uncomfortable with the general direction?
<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 empty soap body in it.
<Marsh> DHull: Recognize this is useful.
<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.
<Marsh> ... We'd have to make a call on whether the anonymous was used for an unexpected purpose.
<Marsh> ... Think I'd lean towards considering that case as a req-resp.
<Marsh> MNot: We're in a place where we need to coordinate with XMLP.
<Marsh> ... How close are we to going to last call?
<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?
<Marsh> DHull: I'll gladly take an action to look carefully at 3.1.3 better in line with 3.1.2.
<Marsh> ... Is there a procedural way to mark this section "at risk", in order to prevent it from being an obstacle at last call.
<Marsh> MNot: We have a dependency on XMLP. We'd have to note that in the document.
<mnot> ack dhull uyal
<mnot> ack dhull uyal
<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?
<Marsh> ... I don't have a good sense of the XMLP timeline.
<Marsh> MNot: We're already dependent upon WSDL doc on WSDL 2.0.
<scribe> scribe: dhull
mnot: take umits point about divide and conquer, but would be concerned about needing to wait
umit: WSDL 2.0 is way ahead of XMLP, so XMLP dependency less of a concern
mnot: Even if we go to LC now or
soon, there will still be time
... XMPL LC Feb-Mar would not hold us up.
anish: hard to say
... XMLP will be F2F at plenary
... 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.
mnot: Publishing this as LC would give them something to shoot for.
anish: At least we get the rest of this stuff out for comment.
mnot: Can ask if editors feel comfortable (after 66) folding in these proposals.
marsh: Is this absolutely
fundamental? What if XMLP doesn't converge?
... Can we insulate by referring to "one-way" generically
mnot: could publish but could we test?
dhull: could we note assumptions made for testing?
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.
marsh: worry is that people would interop to this and XMLP would contradict this.
mnot: if we can interop and XMLP doesn't say anything, what's the problem?
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
... Then say that actual binding has to be equivalent. We get
interop.
dhull: basically what non-normative note in original proposal was aimed at.
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.
marsh: all true, but still
concerned about interaction with XMLP. Haven't seen a lot of
speed from XMLP.
... Don't expect them to speed up significantly. Dependency
worries me.
... Thought dave o's proposal had merit.
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.
... as backup plan.
... Can't test MEP doc on its own anyway. Need binding to
test.
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?
daveo: right.
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
daveo: Nice thing about such a MEP is it gives us that abstraction. Putting it on SOAP 1.1 would not change wire behavior.
umit: People in my company would be upset. Don't expand scope and change SOAP 1.1.
daveo: How to handle non-anonymous?
umit: already done for SOAP 1.1 in my proposal. Let's not repeat work.
mnot: Think we have way to move forward process-wise. Will talk to team. Let's re-focus on this.
anish: Want to understand
schedule. First go to last call, hope XMLP is in LC before
we're in CR.
... Deliverables in XMLP charter mention LC for one-way MEP in
March 2006.
<anish> http://www.w3.org/2005/07/XML-Protocol-Charter.html#deliverables
anish:
http://www.w3.org/2005/07/XML-Protocol-Charter.html#deliverables
... could do what DaveO suggests: put in an abstract MEP for
leeway, but do we need uber-MEP or just generic SOAP
one-way?
mnot: Already fairly
abstract.
... Other discussion of i059: disposition of section 3.1.2
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/0021
mnot: Marc didn't think majority
of text belonged in WSDL binding doc. Some agreement. Item 5
was similar: should we reference WSI BP?
... 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
... (maybe XMLP)
umit: Do we have another chance to move CR back to LC by including this text?
mnot: That was option 2. Would move SOAP doc back to WD.
Glen: Does it have to?
mnot: It's a substantial change.
anish: Can go to LC instead of WD.
mnot: With permission of director.
glend: WSDL did this
umit: Wouldn't option 3 put us in
same boat?
... Similar with media types in WSDL
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
umit: Have heard concerns about referencing note not in rec track.
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.
umit: Does this mean we don't have to deal with 1.2
mnot: I was talking about 1.1. Are you talking about 1.2 as well?
anish: Marc's objection is that we're talking about a SOAP binding. Not a problem in the 1.2 case.
mnot: We're talking about extending a 1.1 binding, doesn't really belong here.
umit: don't have to solve 1.2 at all, SOAP 1.1 becomes note, we're done.
mnot: Don't have to come up with binding for 1.2
<uyalcina> s/SOAP1.1/SOAP 1.1 behaviour we define/
anish: Some form of section 3.1.3, 3.1.2 as note.
mnot: What would reference look like? Normative, otherwise
anish: Normative for 1.1
... WSDL binding would have SOAP 1.1, normatively points to
note, 1.2 points to XMLP
katy: What sort of process does note go through?
mnot: Relatively lightwieght
umit: Depends
mnot: can add more requirements
katy: still normative?
mnot: stable reference, but not a
W3C REC
... Normative doc about 1.1 would be strange, as 1.1 is not a
REC
umit: referencing media types normatively was not liked by W3C.
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.
... WIll have to talk to team about this in any case, as it's
publishing another document.
... assuming that process will work, are people amenable on
this subissue?
omnes: silence
tony: Not ideal but will do.
Glen: pragmatic solution
mnot: useful outside WSA? Would be argument for separate doc.
umit: Why would (3) be better than (2)
mnot: don't want to go back to WD on SOAP binding absent a real technical problem. This is basically an esthetic issue, right.
umit: Marc might disagree.
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.
mnot: not sure
katy: Could we go for (2) and treat it as an extension and not go back to WD?
mnot: Does anyone think this isn't a substantial change?
katy: not suggesting it's not substantial, but have we considered the possibility
glen: interesting to explore. Will this really change implementor's behavior? Outside of WSDL, maybe not.
mnot: That's not what process says. Would it change implementor's experience in reasonable case.
katy: Key question is would impls
still interoperate?
... If no, would have to consider going back.
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.
marsh: agree
anish: We're talking about 202
coming back in SOAP 1.1. How many impls will barf. From XMLP
call, not many.
... So practically, many impls already handle what we're
proposing.
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)
... Could close i059. If there are issue, can revisit.
marsh: 3.1.2 (dhull) would go in WSDL spec?
mnot: Yes.
Marsh: so bailing on Marc's proposal?
mnot: No, that's the SOAP 1.1
stuff.
... 1.1 section would reference external doc, 1.2 would
reference upcoming XMLP.
marsh: NAK
... Thought Marc wanted to push some material (including text
from 3.1.2) into SOAP CR doc.
several: This was about SOAP 1.1/HTTP, not about SOAP 1.2 MEPs
mnot: What would make you more comfortable?
marsh: Heard displeasure from Marc, not sure how this is to be resolved. Do we expect him to be happy with this?
mnot: Marc mainly wanted HTTP binding stuff out of WSDL doc.
daveO: Share some of Marc's concerns about binding description in WSDL extension.
Glen: +1
mnot: Will split off this as separate issue, need to talk to team. Late bind decision of just where section 3.1.2 gets pushed to.
TonyR: Seems OK
mnot: Adding Umit as editor of
WSDL doc. So editor's discretion effectively means Umits.
... Objections to closing i059 as WD issue with proposal 4 (3 +
addendum) + editors' discretion?
anish: Question: If we have issues (say from WSRX) then we open new issue and go from there?
mnot: Yes.
... Can raise informal issues for interpretation, new info
(e.g. from external group) can raise new issues.
... If no info but people just don't like this in a couple of
weeks, alea iacta est.
umit: As person who would integrate this, will have to crisply define what we mean by one-way MEP before we're done.
katy: Separate decision just what
one-way MEP means.
... Voting on umit's text + addendum
glenD: not comfortable with addendum.
mnot: comfortable with substance.
glenD: uncomfortable with
switching MEPs on the fly. Relates to old async TF discussion,
current XMLP discussion.
... 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.
... 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.
... This approach seems to limit usefulness of abstraction.
DaveO: Don't understand
distinction being made. I've tried to separate out "either
there is a response or not".
... 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.
... Then there is the actuality of whether a response happens
on the wire.
... 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.
mnot: So can we go ahead?
daveo: Would like to see actual combined text, but seems reasonable to me to do binding by reference, nto value.
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.
... Seems less clear to say "binding can be request-response or
one-way and won't know until runtime".
daveo: Flexible MEP is just playing a shell game, if it can go either way.
Glen: HTTP gives value: either there is a body or not, some status code, etc., this is useful.
daveo: yes but ... at SOAP level, the notion of a MEP not telling you there will be a response has no value.
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?
... There will definitely be issues with 3.1.3. 2) Is close
i059 and have LC issues with it
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.
umit: This particular issue is in front of XMLP. Pessimistic about resolving SOAP 1.2 text comfortably.
<bob> yes
<Zakim> anish, you wanted to say that if we decide to go with option 2, we can still take the Note to LC
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.
<uyalcina> +1
anish: Could we split i059 into SOAP 1.1, SOAP 2.2
katy: +1
mnot: A bit tricky, but we can
see.
... Straw poll. Comfortable with closing i059 as currently
proposed, with friendly amendment to describe both possible
models in 3.1.3
marsh: comfortable
bob: comfortable with seeing some text on that.
mnot: can still raise issues
<TRutt> comfortable, but would like rights to question words
daveo: uncomfortable
<gpilz> uncomfortable
glen: want to see whole thing before going forth
marsh: Had meant to say "uncomfortable"
<TRutt> I would like to see the words before closing
<Nilo> same here
daveo: I could put together a new combined proposal
several: 1.2 text main source of discomfort.
<TRutt> agree 1.2 is my main discomfort
<gdaniels> +1
<TRutt> +1 to close 59 with 1.1 text as is
various: confusion as to just what is being closed
umit: Can address 1.2 separately
mnot: any objection to closing i059 with proposal 3 + opening 2 new issues
daveo: very uncomfortable with
closing this way. Can live with it.
... what have we gained?
umit: using addressing, anonymous markup goes into text.
marsh: still uncomfortable with
"prohibited" value
... 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.
mnot: Will split into three issues, expect to close first soon. Chunking up is only way forward.
<scribe> ACTION: Dave Hull and Dave Orchard will re-work SOAP 1.2 proposal to address concerns raised today. [recorded in http://www.w3.org/2005/12/12-ws-addr-minutes.html#action03]
mnot: Any response on XMPL issue 39?
omnes: silence
<mnot> ACTION: David Orchard to revise David Hull's proposal WRT SOAP 1.2. [recorded in http://www.w3.org/2005/12/12-ws-addr-minutes.html#action04]