[Standards] Christmas Presence
justin-keyword-jabber.093179 at affinix.com
Tue Jan 4 18:35:54 UTC 2011
On Tuesday 04 January 2011 07:03:56 Dave Cridland wrote:
> 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.
I think it's going to have to be (b). Clients assume a blank slate at session
start, which is why the bare-jid unavailable works today in the way you'd
expect. However, in general, I believe clients treat bare-jid presence as
referring to a single session with a 0-length resource (residual effect of how
legacy transports would send out resource-less presence). So, I would expect
that existing behavior would be for the client to remove an empty session if
it exists, but not to touch any other sessions.
> 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.
I agree that dropping dups is fine. My feeling with presence is that it
indicates an ongoing state. The stanza transmission alone is independent of
this state. Similarly, it should be possible to intentionally replay presence
without effect to that state (as servers already do).
More information about the Standards