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

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed May 17 15:01:24 UTC 2006


> S2S routing? Are we talking about the same architecture,
> http://www.xmpp.org/specs/rfc3920.html#arch-network
> with direct connections between any two servers?
> 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
mentioning the base requirement of every stanza from JID being set by a
standard compliant server. I am just describing at a perfectly compliant
stanza that would achieve the expected result. I did not say we would not
loosing some bytes in the process, but from an XMPP standpoint we would be
standard, and only sending a single stanza ;)  

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...

Keep going

Jean-Louis

-----Original Message-----
Message: 3
Date: Wed, 17 May 2006 09:20:00 +0200
From: Philipp Hancke <fippo at goodadvice.pages.de>
Subject: Re: [Standards-JIG] proto-JEP: Smart Presence Distribution
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <446ACEA0.8050603 at goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Jean-Louis Seguineau schrieb:
> This JEP highlights a point where XMPP could improve its presence
> distribution model. Obviously we would streamline traffic by delegating
> probing and advertising to the target server. The greater gains thought
> would only be achieved when a particular user has more than one contact
> located on a remote server. If one user has a widely spread remote contact
> distribution (i.e. many remote contacts each on different servers), the
real
> gain would be lower than expected. 
For the record: you even gain some bytes when there is just a
single contact on the remote server.

> But beyond any discussions about how much traffic decrease would be
> incurred, the proposed implementation will break the XMPP inter domain
> routing. And that is not acceptable.
> 
> I could also agree to add some extension inside a <presence/> stanza
> indicating it is a 'smart unicast' destined to a remote server. It must in
> any case be addressed to the remote server, because without a 'to'
attribute
> for an s2s, routing becomes impossible.
S2S routing? Are we talking about the same architecture,
http://www.xmpp.org/specs/rfc3920.html#arch-network
with direct connections between any two servers?
We're only talking about leaving out 'to' on the S2S wire.

> If we believe the gain of this approach is worth modifying servers
behavior,
> I propose to change the implementation to something like
> 
> <presence from='romeo at montague/inlove' to='capulet'/>
> 
> Or if we want to be more specific
> 
> <presence from='romeo at montague/inlove' to='capulet'>
>     <broadcast xmlns='some_new_xmpp_namespace'/>
> </presence>
> 
> In both cases note the to attribute with the bare JID of the remote
server.
Can you possibly get that information from stream:to?

Philipp




More information about the Standards mailing list