[Standards] Proposed XMPP Extension: Client State Indication

Holger Weiß holger at zedat.fu-berlin.de
Thu Aug 28 14:16:45 UTC 2014

* Kurt Zeilenga <kurt.zeilenga at isode.com> [2014-08-19 15:52]:
> What you seem to what, and I must admit I'm guessing to some degree, is
> guidance on how to implement behaviors of one those states, namely the
> inactive state, or possibly you want the spec to be quite prescriptive
> in the behaviors associated with each of the states.

I think the question is whether or not the server behaviour might have
interoperability implications, and to me it's not that obvious that it
won't.  I can well imagine client authors who would be happy if they
could rely on the consequences of indicating inactivity.

> If you rather have a different protocol, such as one which was more
> prescriptive in the behaviors of the server's behaviors when the client
> is inactive, then you should write up a separate XEP because, as I think
> Matthew has indicated, this spec is intended to define a simple protocol
> which is more descriptive or even just suggestive of the behaviors.

If you ask me, it would be awesome if we managed not to end up with
multiple XEPs to solve the given problem.  While I'm a little unsure
about the interoperability thing, I really like the simplicity of this
proposal, and I'd definitely prefer having just this one both over
having none at all _and_ over having two of them.


More information about the Standards mailing list