Re: [Stox] chat states <-> isComposing

Saúl Ibarra Corretgé <> Thu, 19 September 2013 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3322D21F99C0 for <>; Thu, 19 Sep 2013 00:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.818
X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wx54l55Moq0Z for <>; Thu, 19 Sep 2013 00:44:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D19D21F99C3 for <>; Thu, 19 Sep 2013 00:44:08 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 4B157344002; Thu, 19 Sep 2013 09:44:03 +0200 (CEST)
Received: from imac.saghul.lan ( []) by (Postfix) with ESMTPSA id 52E5CB00EF; Thu, 19 Sep 2013 09:44:03 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <>
In-Reply-To: <>
Date: Thu, 19 Sep 2013 09:44:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Peter Saint-Andre <>
X-Mailer: Apple Mail (2.1085)
Cc: "" <>
Subject: Re: [Stox] chat states <-> isComposing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Sep 2013 07:44:22 -0000

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:

> Hash: SHA1
> 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

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

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

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.


> 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.

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


Saúl Ibarra Corretgé
AG Projects