[Standards-JIG] proto-JEP: Smart Presence Distribution

Michal vorner Vaner michal.vaner at kdemail.net
Wed May 17 17:28:23 UTC 2006

On Wed, May 17, 2006 at 06:33:52PM +0200, Carlo v. Loesch wrote:
> Jean-Louis Seguineau typeth:
> | > We're only talking about leaving out 'to' on the S2S wire.
> | 
> | I am just saying this breaks section 9.1.1 of RFC3920 for s2s, not
> 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.
> 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'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.

If you think few bytes on a wire are worth making the protocol
complicated (and syncing rosters between servers would be complicated
for sure), then you probably should choose another protocol. I guess
jaber tries to be as simple as possible.

And no, you can send message to more people even with this jabber
protocol. You have MUCs, you have advanced addressing and you can always
send more stanzas. Where is the problem? Who do you think will take his
long hours to write, debug and maintain this thing that will save _few
bytes_. In the meantime he writes it, we will have double the fast

> | My point was only about protocol level compliance. But now that Till started
> | 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 to
> | explain how you will cater for it. That is probably a tougher nut to
> | crack...
> 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.
I disagree here. You have the roster in more than one place. Such a
situation always leads to bug which are hard to detect and even harder
to find. This is the situation half of programing textbooks warn

And again, you have to send your roster to other server. This will not
be welcome by companies, by people who has frinds on big public servers,

And, take jabber.org, for example. I do not how many it has users, I do
not know how big the database of their rosters is. But could you imagine
it would have to remember rosters of probably all (well, nearly anyone
has someone on jabber.org server, right?) jabber users. This is big
problem of scalability, since the size of data is growing with the size
of the whole network on every server.


Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060517/ea3320e9/attachment.sig>

More information about the Standards mailing list