[Standards] Proposed XMPP Extension: Stanza Repeaters

Peter Saint-Andre stpeter at stpeter.im
Fri Mar 21 17:34:09 UTC 2008

Philipp Hancke wrote:
> Peter Saint-Andre wrote:
>> Philipp Hancke wrote:
>>> But while writing a script to calculate those numbers I found an
>>> interesting claim in the draft:
>>> (S2) Number of outbound presence notifications = (S1*C4).
>>> (T1) Number of unavailable presence notifications = 1 per online contact
>>>  (C4).
>>> Why are those restricted to 'online contacts'? As far as I can see, RFC
>>> 3920 says
>>> "in which case the server to which the entity is connected SHOULD
>>>  broadcast or multiplex that stanza to all subscribing entities."
>>> I don't see any "online" in there.
>> Your server sends unavailable presence only to people to its internal
>> "avails list" (people to whom it has sent online presence based on probe
>> data or to whom you have sent directed presence). It doesn't need to
>> send unavailable to everyone who has subscribed to your presence. Or, at
>> least, that's an optimization 
> Interesting optimization - as far as the traffic savings are concerned.
> Yet it breaks invisible (at least): it makes the sender appear online to
>  the other side indefinitely.

Invisible is broken anyway. And which version of invisible are you
talking about? And no it doesn't break that, because the server sends
unavailable when you go invisible.

>> many server implementations perform.
> Which ones? I've just tested jabberd14 and ejabberd and neither of
> those stops sending me presence updates or unavailable.
>> Perhaps it is not clearly described in RFC 3921 or rfc3921bis.
> Could you point to to the paragraph where it is described at all?
> 5.1.1, 5.1.2 and 5.1.5 only talk about not sending to contacts which
> have bounced back an error (and even that sounds like a bad optimization
> to me).

Section 4.4.2 of rfc3921bis says:

Note: As an optimization, if the subscription state is "both" then the
user's server MAY choose to broadcast subsequent presence only if the
server has received available presence from the contact at some point
during the user's session; i.e., if the server never received available
presence from the contact and the user has a mutual presence
subscription with the contact, it MAY decline to send subsequent
presence to the contact.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080321/9f399cb8/attachment.bin>

More information about the Standards mailing list