> In addition that it is currently used for two different purposes: Actually, it looks like three purposes: time since last online, idle time (clients), and current uptime (servers/components).
> 2. Discover when a connected user was last active at the server. (The XEP > calls it idle time, which would be some kind of server access idle time if i > read it right) For clients XEP-0012 says that idle time is based on human interaction with the client. From section 4: > If the user's server delivers the IQ-get to one of the user's available > resources, the user's client MAY respond with the idle time of the user > (i.e., the last time that a human user interacted with the client > application)." As for the proposals: > Purpose 1) can be done using presence + delayed delivery, like described at > http://tools.ietf.org/html/rfc6121#page-54. This would automatically use > absolute time. +1. If it's handled appropriately in the core RFCs, no need to duplicate it in a XEP. > Don't think 2) is the semantic we ever wanted. Under idle time I understand > the time someone has been away from his machine/device. The most common way > to detect this is missing input (keyboard/mouse/touch). In my opinion neither > XEP-0012 nor XEP-0256 describe such behavior. That looks to be what XEP-0012 and XEP-0256 already prescribe, but given the overloaded meaning of terms in XEP-0012, +1 on simplifying. > That's why I propose to use a new protocol, like this > https://dl.dropbox.com/u/14672346/xmpp/extensions/xep-0256-replace.html . My only suggestion for the proposed replacement is to just go ahead and name the element <idle /> instead of <last-interaction />. It's shorter (good for presence data) and the intent (user has been idle since) reads nicely. This leaves the third use case for server/component uptime reporting uncovered, but that seems like something that should be done via adhoc commands like other statistics reporting, and probably already is. -- Lance
smime.p7s
Description: S/MIME cryptographic signature
