[Standards] XEP-0085 state chart

Florian Zeitz florian.zeitz at gmx.de
Thu Aug 27 00:03:59 UTC 2009

Hash: SHA1

Peter Saint-Andre wrote:
> Today in the xmpp:jdev at conference.jabber.org room we had a bikeshed
> discussion about the various transitions in Chat State Notifications
> (XEP-0085)...
> http://logs.jabber.org/jdev@conference.jabber.org/2009-08-26.html#15:12:36
One quick note about this: Some people have mentioned during the
discussion they find this whole XEP pointless and calling this a
bikeshed discussion has a similar impact. I think it implies that this
is not really worth discussing, which automatically degrades any answer
to the question, which could probably be seen as an insult to somebody
who does care, or even who bothers to join the discussion.
That said I personally don't care that much either, the following is
just to put another point of view out there.

> I suggest that the following are the most common/sensible transitions:
>                 o (start)
>                 |
>                 |
>     |                                       |
>     |                                       |
>     +---<---<---<---<---<---<---<---<---<---+
> Someone suggested that you might want to do things like go from
> <inactive/> to <paused/> if a user returns to a chat session interface
> containing an unfinished message. I have no deep objection to such a
> transition, though it strikes me as a bit odd. My reasoning is that the
> <active/>, <inactive/>, and <gone/> states refer to the overall chat
> session interface whereas the <composing/> and <paused/> states refer to
> the message input interface (and are in some sense a subset of
> <active/>, so that you would go from <paused/> to <inactive/> but from
> there back to <active/> and then <composing/>).
I would return to <paused/> for the same reason. <paused/> means someone
has been composing  and is active (both intentionally without </>),
which to me is obviously the case if the message input interface is not

> As I said this is painting the bikeshed and I'd just as soon leave the
> supported state transitions up to the implementation so that we don't
> need to argue about the spec all the time, but if people care about this
> I will update the spec.
As said in the discussion I think that might be the way to go if
implementors stand by their different opinions.
Version: GnuPG v1.4.9 (GNU/Linux)


More information about the Standards mailing list