[Standards] XEP-296 problem?

Mark Rejhon markybox at gmail.com
Wed Aug 15 17:04:49 UTC 2012


On Wed, Aug 15, 2012 at 11:45 AM, Yann Leboulanger <asterix at lagaule.org> wrote:
> Hi,
> I was wonder what should I do in this situation:
> user A and B are connected with resource r1. They that, so messages go from
> A/r1 to B/r1.
> user B connects a second client with resource r2 with a higher priority.
> Where should go next message of user A?
> Someone pointed me to XEP-0296 which clearly answer the question: next
> message should go to bare JID.
> So I started thinking how to implement this XEP, and came to a problem:
> let's imagine that r2 is LOWER prio than r1. XEP-0296 says that we still
> need to go to "unlock state". This mean starting a new thread of course as
> we don't know which resource will get it. But if the begining of the
> conversation was crypted? or if we negociated the log options or anything in
> XEP-0155, then we need to restart the negociation?
> Same thing if B just go away or na? so we cannot continue en encrypted
> conversation if we go away?
> So dealing with several resouces is still very complexe, and I'm not sur to
> have the answer to my first question now.
> Any idea on how I should implement that?

While 0296 is quite good for a lot of cases, I have come to many
scenarios where I didn't really like XEP-0296 much, inclyuding when it
came to certain usages with real-time text (XEP-0301), but it makes
sense.  I've designed my 0301 spec to be acceptable regardless of
which conversation locking mechanism is used (or not), as some clients
have sometimes chosen to "prefer" bare JID (since Google Talk will
broadcast the same message to all resources).  This is not a behavior
done by all XMPP servers, so this is not to be relied on, though some
users like this behavior since it eases device-switching (e.g.
switching between a PC and a tablet/smartphone) while preserving
incoming-messages history on both devices simultaneously, even though
this is kind of frowned on by the XMPP standards (but not explicitly

I imagine, that since XEP-0296 only defines a "SHOULD" rather than a
"MUST", it means XEP-0296 is leaving the door open a crack, for
extenuating situations.  For example, you can design your client to
handle certain situations (such as preserving encryption) differently,
and there seems to be many possible outcomes.   Is keeping encryption
important?  Is keeping the original stream of messages important?  Is
it a problem solved by re-negotiating encryption?  Where resource r1
is encrypted and resource r2 is unencrypted, there may be extenuating
situations to use different rules/behaviours.

One example is you could also even handle r1 (encrypted) and r2
(unencrypted) as separate, independent conversations (separate chat
windows), in order to preserve encryption with r1 (because
0296-compliant unlock would break the encryption).   Some chat clients
seem to handle special situations this way, using a separate chat
window per full JID.  That behavior isn't banned by XMPP, even if it
might be discouraged.  You have some tradeoffs and compromises to

Mark Rejhon

More information about the Standards mailing list