[Standards] Proposed XMPP Extension: Client State Indication

Kurt Zeilenga kurt.zeilenga at isode.com
Wed Aug 20 05:06:10 UTC 2014


> On Aug 15, 2014, at 8:09 AM, XMPP Extensions Editor <editor at xmpp.org> wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Client State Indication
> 
> Abstract: This document defines a way for the client to indicate its active/inactive state.
> 
> URL: http://xmpp.org/extensions/inbox/client-state-notification.html
> 
> The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
> 

I think this ProtoXEP adequately addresses a need for a simple mechanism to enable “best effort” server optimizations of traffic for “inactive” clients.  I believe the specification is clear, concise, and readily implementable.   Isode is considering implementing this specification.

A few comments.

It might be appropriate to note that a server could support SIFT advanced matching on Client State Indication… though I’d make details of this beyond the scope of this document.

Section 3 ends with:
     Regardless of what optimisations a server implements, it SHOULD provide a way for administrators to configure them, and MAY provide such configuration to users also (e.g. through an ad-hoc command).

I’m not a big fan of SHOULD’ing something which has doesn’t have impact interoperability or security or other key characteristic of the protocol. Also I think providing user configuration is a can of worms maybe best not suggested.  Anyways, I offer the following alternative text:
	Server implementations are encouraged to provide, where appropriate, administrative control of which and how traffic is optimized by the server.  While a server is also free to offer means for a user to control which and how traffic is optimized, it is noted a user can multiple devices with different optimization needs and devices that use per stream random JID resource parts.  Regardless, both administrative and user control of server provided optimizations is beyond the scope of this document.

Section 6 says:
   To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other entities on the network.

I would rather make this slightly less than an absolute prohibition.  As worded, this would disallow a server from sharing the clients active/inactive state with an administrative client entity and this would be quite problematic for implementations that have XMPP-based administrative tools.  There may be other cases where disclosure is reasonable.  I suggest instead:
   To protect the privacy of users, servers MUST NOT inappropriately disclose a client’s active/inactive state.

Section 8 says there is nothing for the XMPP registrar to record, but there’s a stream feature to be recorded by the registrar.

Thanks for the specification!  — Kurt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140819/320c00ab/attachment.html>


More information about the Standards mailing list