[Standards] Christmas Presence

Dave Cridland dave at cridland.net
Tue Jan 4 15:03:56 UTC 2011


Irresistable pun. :-)

So, two presence questions to kick off the new year.

1) Bare-jid unavailable presence in mid-session.

If a server receives bare-jid unavailable presence in mid-session,  
should it:

a) Just pass it on to the client, quietly.

b) Send a replicated unavailable for any full-jid presence that's  
known to have been sent to the client. If no such presences have been  
sent, then send a bare-jid unavailable.

My reasoning is that currently, sending a bare-jid unavailable is  
only typically done at the beginning of a session in response to a  
single probe. 3921bis allows us to cache remote presence per-contact,  
so bringing on a second resource might mean that this cache is  
immediately sent - but this *also* means that a probe done now (or  
later - reprobing is now explicitly allowed too) might generate a  
bare-jid unavailable. (It also means we need to handle timeouts for  
probes, too, of course). In addition, bringing a second resource  
online causes, in effect, a reprobe for the first resource - both  
probes happen from the bare jid, so this is a corner case that can  
happen now.

The problem is that while I'm generally quite hopeful that an  
unavailable from a bare jid will be understood by clients prior to  
any presence being received, I'm not so hopeful about it being  
handled when one or more existing resources is around.

I'm not sure what solution I prefer here - (a) is obviously more  
efficient, but (b) may work better.

2) Duplicate presence.

When a server receives a presence from a remote source which is  
"identical" (for some definition) to the presence known to be the  
last transmitted to the client, it should:

a) Send it anyway.

b) Drop it.

My rationale is similar to the above here - reprobes of various forms  
can easily cause multiple redundant presence stanzas. The result is  
really just wasted bandwidth - the client already knows the presence  
state of the remote contact, so retransmitting this state is not  
actually transmitting any information.

The case might be made that there is information present in the  
transmission itself, however that's not the case with reprobing and  
suchlike. Given that additional resources currently act as reprobes,  
each client will receive a full set of redundant presence every time  
another resource from the same bare jid comes online, anyway.

A strict reading of 3921bis suggests that retransmission is required,  
but I suspect that it's within the spirit to elide duplicates.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list