> On Aug 15, 2014, at 8:09 AM, XMPP Extensions Editor <[email protected]> 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
