> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

It removes several sources of ambiguity from XEP-0256, which have been 
discussed on standards@ before (e.g., 
http://mail.jabber.org/pipermail/standards/2012-October/026887.html)

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

Yes

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

I have, in SleekXMPP and stanza.io.

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

No

> 5. Is the specification accurate and clearly written?

Yes



> XEP-256 allows to announce "idle since" time, but only when the show
> type is 'away' or 'xa'. It further allows you announce when the user
> went offline before the current session ("was last online at").

That's the crux of the issue. XEP-0256 actually can't distinguish
between idle & last online in practice, precisely because its 
semantics change depending on the presence's show value (or lack
thereof).

Why is that a problem?

1) We don't have any standard for how auto-changing the show value
   should behave. For example, if I set my presence to 'dnd', should
   my client change it to 'away' or leave it at 'dnd'? I've seen both
   options used by clients; I actually would prefer to keep the 'dnd'
   show value because it is more useful for expressing intention.

2) Client apps tend to try to be helpful and re-use your last sent
   presence as the initial presence when you start the app again. So
   if I manually set myself to 'xa', when I open the app again I will
   typically happen to have an 'xa' initial presence.

In the end, the *only* entities that can in practice reliably
distinguish an 'initial presence' from any other presence update, are 
the client itself and the client's server.


I would say that our experience using XEP-0256 in the field indicates
that it is only useful for idle time (by ignoring the show value), and 
that the last online use case ought to be removed. Hence the start of
XEP-0312 Pubsub Since to make the offline time distinct and explicit.


Because updating XEP-0256 to solve this issue would change the 
existing semantics (for anything that is currently trying to
distinguish between idle & last online), I think it would be best to
make a clean break with a new element and namespace.



- Lance

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to