[Standards] LAST CALL: XEP-0352 (Client State Indication)

Kevin Smith kevin.smith at isode.com
Mon Dec 11 17:13:32 UTC 2017


On 7 Dec 2017, at 17:35, Jonas Wielicki (XSF Editor) <jonas at wielicki.name> wrote:
> 
> This message constitutes notice of a Last Call for comments on
> XEP-0352.
> 
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
> 
> URL: https://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on
> 2017-12-21.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

It was, it’s less clear that it still is. Once upon a time, clients on mobile would continue to run in the background in a useful way, at least on Android (it’s never really been the case for iOS unless you abused APIs), but these days even Android is moving away from this towards other mechanisms that might be more appropriate for us (e.g. Push).

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

The requirement is basically to implement CSI, so yes :)

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Not currently - I don’t think it solves the issues for mobile that it once did, at least in the mid-future, so I’ll be inclined to concentrate on Push and other needed parts (like fast reconnects).

> 4. Do you have any security concerns related to this specification?

I have a feeling that the current prose that semi-recommends bypassing 6120/6121 rules and silently dropping stanzas from the middle of a stream might introduce security issues in subtle ways, although I haven’t yet thought of any.

> 5. Is the specification accurate and clearly written?

I think the suggested-but-not-normative server behaviours either need more fleshing out, or probably shouldn’t be included.
"	• Suppress presence updates until the client becomes active again. On becoming active, push the latest presence from each contact.”
For example can go wrong in interesting ways, depending how you interpret it, and break PEP, MUC, or presence subscribing.

"Regardless of what optimisations a server implements, it SHOULD provide a way for administrators to configure them”

I think this text is trying to avoid a server doing RFC-breaking things without allowing an admin to opt-out. If that’s the case, I suggest that it would instead be better to say that a server MUST NOT introduce any RFC-breaking optimisations by default. If that’s not the case, I think mandating what’s configurable is probably not appropriate.

"If the server supports CSI, it advertises it in the stream features after the client has authenticated:”

I feel like we’ve probably discussed this is the distant past, but it seems (uniquely?) inconsistent to advertise stream features that are only used after the stream is set up and the user could disco instead.

"For example: A client sends a CSI active nonza”

I don’t think using the ‘nonza’ term (and inconsistently at that) is aiding the reading of the XEP here. We can say “element” (as we do elsewhere in the spec) and be at least as clear as nonza, without inventing new, confusing nomenclature.

"That is, stream resumption does not affect the current CSI state, which always defaults to 'active' for new and resumed streams”

I think this intends to say the opposite of what it says, doesn’t it? Stream resumption *does* affect the current CSI state, which it resets to ‘active’.

"To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other entities on the network.”

I’d have thought exposing this to admins of the user’s server is probably fine (plus obvious grammar slip), although maybe that doesn’t need this sentence changed.

/K


More information about the Standards mailing list