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