[Standards-JIG] proto-JEP: Smart Presence Distribution
jean-louis.seguineau at laposte.net
Wed May 17 18:22:10 UTC 2006
Carlo v. Loesch wrote:
> Well obviously as this is an extension to the RFC, we cannot remain
> compatible to it. In fact, when XMPP was about to be published as an
> RFC, we suggested that the one-to-many issue needs attention and XMPP
> should provide for a means of multicasting. Back then several people
> presumed multicast would never become necessary, so the RFC came out
> with multicast inability builtin.
I believe Peter already highlighted the subtle difference between extending
and breaking ;) As to multicast, if you are referring to IP multicast, then
obviously the RFC does not address it. This does not imply that XMPP is not
able to provide efficient information broadcasts in its current form.
Actually, I would argue it does it well.
> Now you have come to the point that multicast is useful after all,
> and we are patiently here again and even proposing how to do it.
> Obviously we can't stick to an RFC which was conceptually built
> against multicast, that's why we are suggesting to give this new
> syntax a new XMPP version number.
I do not believe anyone in the community has ever denied the interest of
broadcasting. But this is more a matter of concept than implementation.
Actually you can achieve similar results using the current XMPP protocol
without the added constraints of unreliability at the protocol level, for
example. But I know a number of other list members which are more qualified
than I am on these subjects. Their opinion certainly matters.
> I'd also like to add a statement Larry Masinter made on the IMPP
> Mailing List on Oct 18, 1999:
> "If you're going to do a standard for Instant Messaging (even 1-1
> messaging), ignoring the requirements imposed by the possibility of group
> > communication would likely lead you to a protocol that doesn't satisfy
> anyone's actual requirements."
> IMPP was then designed without one-to-many in mind, even though
> the mere plan of distributing presence IS a one-to-many operation.
> And here we are, 7 years later, and we know Larry was right.
I am sorry to say I do not have the pleasure of knowing 'Larry'. But I do
not know of any IMPP implementation to date. The same cannot be said about
XMPP. Before talking about 'anyone's actual requirements', it would be sound
to actually expose these requirements, don't you believe? This would make a
stronger case than vague generality. After all, we do build protocols or
applications to solve real world issues. So if we do not know the issue...
| My point was only about protocol level compliance. But now that Till
| on this, the JEP assumes the rosters to be properly synchronized on every
| server. There is no guarantee it would always be the case. You will have
| explain how you will cater for it. That is probably a tougher nut to
> If the rosters are not in sync, it doesn't matter if they aren't in sync
> on the sender's or on the receiver's side. If so far you were able to live
> with occasional glitches and occasional necessity to re-establish a
> subscription, the multicast variant of the operation won't make that more
> or less complicated. It only gives you less traffic on the network.
So you say. This is the whole point. You have so far provided no tangible
evidence, but instead rather vague and dismissive affirmations. Don't you
think it's kind of short as a sustainable alternative?
More information about the Standards