Subject: [Stox] chat states <-> isComposing

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Sep 2013 09:10:45 -0600

I've taken a look at the mapping between XMPP chat states (XEP-0085)
and the isComposing event (RFC 3994).

RFC 3994 has two states: idle and active. RFC 3994 has only two states
because it's really just about composing (in messaging, whether or not
the sender is actively typing or otherwise creating text for sending
to the recipient -- simply toggling between the two, changing to
active if the user is composing a message and changing to idle when
not composing a message).

XEP-0085 has five states: active, inactive, gone, composing, and
paused. XEP-0085 has more states than RFC 3994 because it's not just
about composing, but about the sender's involvement with the chat
session. Thus in XEP-0085, "active" means "paying attention to the
conversation", which ironically maps best to RFC 3994 "idle", I think.

It might be best if we don't map XEP-0085 chat states other than
composing and paused to RFC 3994 isComposing events, since RFC 3994 is
just about composing. However, in XEP-0085 it is possible to have
state transitions such as composing to active (not paused).

Thus the safest mapping might be

isComposing => chat states
  idle => active
  active => composing

chat states => isComposing
  active => idle
  inactive => idle
  gone => ???
  composing => active
  paused => idle

This mapping loses some of the granularity on the XMPP side (i.e., the
paused and inactive states), but that might be fine in this context.

I know Saúl has looked at this mapping, so I would appreciate his
feedback (and input from other folks, too).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 19 Sep 2013 09:44:02 +0200

Hi Peter!

Thanks for looking into this, I think it's really useful.

On Sep 18, 2013, at 5:10 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Yes, I implemented this mapping following my intuition and feels ok in actual usage.

> chat states => isComposing

Here comes the dilemma: that gone state. Not many clients implement the 'gone' state, but those who do tend to render a message such as "Peter left the conversation" if they get one, and likewise, send it if you close the conversation tab. Based on this non-scientific testing I mapped it to a SIP BYE, both ways. That is, if we are having a chat session (I am on MSRP and you on XMPP) if I end the SIP session, the gateway would send a gone chatstate, and if your client would send it, the gateway would terminate the SIP session.

I know this looks weird, since we are mixing payload translation with session management, but since the gateway needs to handle all chat media I don't see a problem with that.

Thoughts?

> paused and inactive states), but that might be fine in this context.

We'll need to adjust to the minimum common denominator, like we do in groupchat :-)

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Sep 2013 06:50:27 -0600

[removing areas of agreement]

On 9/19/13 1:44 AM, Saúl Ibarra Corretgé wrote:

> Here comes the dilemma: that gone state. Not many clients
> implement the 'gone' state, but those who do tend to render a
> message such as "Peter left the conversation" if they get one, and
> likewise, send it if you close the conversation tab. Based on this
> non-scientific testing I mapped it to a SIP BYE, both ways. That
> is, if we are having a chat session (I am on MSRP and you on XMPP)
> if I end the SIP session, the gateway would send a gone chatstate,
> and if your client would send it, the gateway would terminate the
> SIP session.
> 
> I know this looks weird, since we are mixing payload translation
> with session management, but since the gateway needs to handle all
> chat media I don't see a problem with that.

That makes a lot of sense to me, given that the gone chat state is
kind of like in-session unavailable presence.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/