XMLP Teleconference Minutes

18 Oct 2006


See also: IRC log


David_Hull, Yves, Marc_Hadley, cferris, anish, noah, Dave_Orchard
Chris Ferris



chris, can we get some time on the agenda to talk briefly about mtom policy assertion?

<scribe> Scribe: anish

Agenda bashing

Approval of minutes http://www.w3.org/2006/10/11-xmlprotocol-minutes.html

minutes approved

AI reviewed

<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

Discussion of multicast

chris: no consensus yet
... need to figure out a way forward on this


<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

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
[DONE] ACTION: editors to incorporate noah's proposed text above [recorded in http://www.w3.org/2006/10/18-xmlprotocol-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/12/04 10:22:27 $