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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
