See also: IRC log
chris, can we get some time on the agenda to talk briefly about mtom policy assertion?
<scribe> Scribe: anish
minutes approved
<scribe> ACTION: chris to re-stimulate the thread with noah/david's note : considered moot [recorded in http://www.w3.org/2006/10/18-xmlprotocol-minutes.html#action01]
<scribe> ACTION: editors to incorporate noah's proposed text above -- done [recorded in http://www.w3.org/2006/10/18-xmlprotocol-minutes.html#action02]
<scribe> ACTION: chris to add the mtom policy assertion in next week's agenda [recorded in http://www.w3.org/2006/10/18-xmlprotocol-minutes.html#action03]
Anish: need a minute or too to talk about mtom policy assertion
chris: will add it towards the end
chris: no consensus yet
... need to figure out a way forward on this
http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0021.html
<noah> Reminder: options were
<noah> 1) No multicast...just a unicast, called one-way unicast or some such.
<noah> 2) Just a "multicast enabled one way"
<noah> 3) Two separate MEP notes, one multicast-enabled and one not.
daveo: option 3 or doing two different docs is
a bad solution. Not in favor of that.
... strongly opposed to that
... BEA can live with either option 1 or option 2
... why have 2 docs. not a lot of utility in maintaining two docs. If the
diff between the two docs is extreme then there are goin to be radically
different impl. If so, then outside what we were chartered to do
<Zakim> noah, you wanted to talk about radically different implementations
noah: i think that is a good analysis. I'm more
positive about doing both is that multicast implementations are different
than unicast and having a label that distinguishes them is helpful
... i would be happy not to mess with multicast at all. But if we need
consensus then i would be ok with 2 docs.
marc: we have a strong preference for #1
... would not lie down in the road for option 3
... but see it as a waste of the WG time.
<marc> not in favor of 2 at all
daveo: if option 2 could be done right now, it is preferrable. but if it is going to take 3 months then option 1
noah: most of us don't think that the time
difference between the two is huge
... option 2 is the baseline, getting to option 1 is a question of
hours/days
... either one won't result in huge time lag
<noah> Looks to me like someone is rejecting each option?
chris: my preference is either 1 or 2, but if 3 is the only way to get to consensus then i could live with it
<noah> DavidH is against 1
<noah> Marc is against 2
<noah> DaveO is against 3
chris: i'm wondering which one is the least painful way forward
<noah> I'm not happy with 2, but will live with it if that generates consensus, but Marc implies that doesn't help.
<Yves> Yves is against 3 (iirc)
<Yves> ... and wanted a multicast agnostic MEP, and multicast/unicast bindings
noah: daveh vetos 1, daveo vetos 3, marc vetos 2
daveh: option 2 is agnostic to multicast
marc: the reason i'm not on most of the meeting cause I don't have the resources to put in this. Multicast was never in the charter
<Yves> I think that a multicast MEP is different from a one way MEP with a binding trying to shoot itself in the foot by doing multicast :)
daveo: my company has no interest in standardized MEP for multicast
marc: we really want option 1, we can live with
option 3. Extra work is waste of time.
... option 2 will produce something that is more complex
<noah> I note that my position and Marc's are pretty much identical, except that I may be a bit more willing to live with (2) as a compromise than he seems to be. Still, our positions are basically identical at their essence.
marc: we are going to run into lost of issue
when we allow multiple messages.
... not sure if we'll file a formal objection
Chris: it sounds like you would not engage in
helping
... marc + noah opposed to 2
<noah> To be clear: I will live with (2), just not that happily. My preferences are: (1) fairly strongly in favor (3) preferred compromise if mcast is needed (2) will live with, but just barely
anish: order of preference: 2, 1, 3. No resources to put into this.
chris: significant majority for 1
daveh: yves, anish, and i prefer 2
... marc, ibm prefer 1
... there is extra work in restricting unicast
... what bindings would you envisage and how would you use the MEP
Noah: possibly MQ, UDP, TCP
Chris: i thought I heard that we could go with (2) and most people don't have resources to go with this
Noah: i'm an advocate for 1
... my personal feeling is that the work required for (1) and (2) is
similar
... there is some fuzziness that needs a clean up
... doing (3) is some more work. Choosing between (1) and (2) does not result
in additional work
daveh: my concern is not writing the mep but the use of the mep
<discussion on what daveo's preference/intention was>
Noah: order of preference: 1, 3 and 2. Can barely live with 2
daveh: will not lie down against option 1. But
have made arguments in the past that option 1 just looks good, but when the
rubber meets the road it is going to be more complex
... reject that it is simpler.
Chris: anyone opposed to option 2?
Yves: if the mep is agnostic as possible. If
people want to shoot themselves in the foot if they use it for multicast,
then so be it. So I'm not opposed to option 2. Would want the MEP as agnostic
as possible.
... best way to describe multicast is to use multicst MEP
marc: i'm hearing that it is not going to be
any more work to do option 2
... the past discussion has been about multicast as opposed to unicast. Is
everyone else at a point that all the problems with multicast are
resolved?
daveh: there were issues but they were generic and they weren't large
noah: little stronger. There are specific
issues against multicast.
... the difference between the two are in terms of days
... the deeper question is an architectural one.
... i'm willing to join daveh in saying that the difference is not in terms
of weeks.
marc: my impression was that there was a lot of
work to do with multicast
... i'm hearing that this is not the case
... don't want to spend couple of month on this discussion
... if everyone is happy with (2), not going to lie down in the road saying
'no'
noah: if the draft isn't ready in say 10 days and the issues are big then we can reopen the decision
chris: am i hearing that option 2 is a way
forward?
... going to lose Noah for 2 weeks. hard to get everyone on the call cause of
vacations, summer etc
... everyone is busy
... concerned about the delta between the two. May be under-estimating the
time required.
<Yves> I don't want to says that multicast is explicitely allowed, and I think that option 2 is not saying that. It should at least warn against the use of the one way MEP for things beyond unicast one way
chris: How about giving a go for 3 weeks, upto US TG
daveh: willing to work with the editors on this
noah: there was a list of unresolved issues
sent by daveh
... 3/4 issues
... pretty bounded
... don't think they are tricky
<cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0021.html
<discussion on the issues and how big/easy they are>
chris: marc, reluctance to support (2) is diminished
marc: still reluctance, but no formal objection
chris: looks like we'll have to go with option 2. Option 1 will result in an objection. Noah is willing to live with option 2.
<noah> I very strongly disagree with what David Hull just said. I don't think issues will arise only if people want multicast. On the contrary, I think the issues will arise when people who are only prepared to send one message try to convince themselves they don't need the capability of doing more.
<noah> The MEP needs to make very clear that a particular binding that's unicast-only is conforming.
<dhull> Yes. One obligation of the binding writier is to narrow "the MEP doesn't say how many recipients" to "in this binding, there will always be exactly one".
<cferris> RESOLUTION: pursue Option 2 for a few weeks and recalibrate how close we are to closure
<dhull> (or not narrow it down)
<cferris> ACTION: Chris to send note to list documenting process forward to completion of oneway MEP note [recorded in http://www.w3.org/2006/10/18-xmlprotocol-minutes.html#action04]
<Yves> well one recipient might be one multicast group, but it's still one recipient address, below the address unicity, there is room to lots of hairy issues
<Yves> so I'm for the unicity of the recipient address in the MEP
<dhull> Yes, one address -> 0 .. N SOAP nodes processing the message.
<dhull> (e.g., I'm using TCP but more than one SOAP node is listening on that physical address)
<cferris> anish: recounts the discussions ongoing in WS-I BP and elsewhere that XMLP possibly should be the most appropriate home for a policy assertion for MTOM/XOP
<noah> Clarify: I assume that the policy assertion relates to a particular port? Presumably you don't see MTOM at the envelope level, right?
marc: if ibm/ms can submit their prorietary assertion it would be faster
anish: i don't think it is a lot of work
daveh: sounds like a good thing and not a lot of work
noah: mtom is something that is asserted at the
wsdl port
... has the community thought about this, is this going to take a long
time
chris: this wg is better suited to do this
rather than ws-i bp or wsd wg
... i would set out a note on getting consensus on the multicast issue
Meeting adjourned