Re: [Stox] chat states <-> isComposing

Saúl Ibarra Corretgé <saul@ag-projects.com> Thu, 19 September 2013 07:44 UTC

Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3322D21F99C0 for <stox@ietfa.amsl.com>; Thu, 19 Sep 2013 00:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.818
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx54l55Moq0Z for <stox@ietfa.amsl.com>; Thu, 19 Sep 2013 00:44:16 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19D21F99C3 for <stox@ietf.org>; Thu, 19 Sep 2013 00:44:08 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 4B157344002; Thu, 19 Sep 2013 09:44:03 +0200 (CEST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (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?= <saul@ag-projects.com>
In-Reply-To: <5239C275.9080402@stpeter.im>
Date: Thu, 19 Sep 2013 09:44:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5FD7851-B085-4174-9804-2840F8963C91@ag-projects.com>
References: <5239C275.9080402@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1085)
Cc: "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] chat states <-> isComposing
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=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:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

Thoughts?

> 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 :-)


Cheers,

--
Saúl Ibarra Corretgé
AG Projects