[Standards] XEP-0012: Last Activity's future
Hi, So currently we have XEP-0012 which we don't like because of the relative time semantic, it uses. In addition that it is currently used for two different purposes: 1. Discover the time a disconnected user last accessed its account (i.e. was online). 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) Note: XEP-0256 seems to do the same as 2) but using presence. I suggest we deprecate XEP-0012 and XEP-0256. 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. 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's why I propose to use a new protocol, like this https://dl.dropbox.com/u/14672346/xmpp/extensions/xep-0256-replace.html . Not to forget the suggested security notice, suggested by Matt, to Date and Time Profiles on possible geo privacy leak. Opinions? Feedback? Cheers, Tobi
Re: [Standards] XEP-0012: Last Activity's future
So currently we have XEP-0012 which we don't like because of the relative time semantic, it uses. In addition that it is currently used for two different purposes: 1. Discover the time a disconnected user last accessed its account (i.e. was online). which is solved by http://xmpp.org/rfcs/rfc6121.html#presence-probe-inbound bullet 3 these days. Actually I doubt anything but jabberd1 implements the 0012-way.
[Standards] pubsub purge_offline
Folks, It looks like purge_offline's behaviour in XEP-0060 is entirely undefined. The pertinent bits seem to be: 1) That purge_offline means: Whether to purge all items when the relevant publisher goes offline 2) That, when talking about a normal purge a purge request MUST NOT result in sending the same notifications as are sent when deleting items (since purging a node with many persisted items could result in a large number of notifications); instead, the node MUST send a single notification to each subscriber, containing an empty purge/ child element. and that's it. So the closest thing I can see to prescribed behaviour is that when doing a purge_offline because a publisher went offline their items are silently removed and that if the node is now completely empty a purge.../ notification is sent. This still doesn't seem entirely satisfying, but the only other option seems to be sending retract notifications for all of the items removed, which (2) says a purge explicitly MUST NOT do. Thoughts? /K
Re: [Standards] pubsub purge_offline
On 2013-02-18 17:34, Kevin Smith wrote: Folks, It looks like purge_offline's behaviour in XEP-0060 is entirely undefined. The pertinent bits seem to be: 1) That purge_offline means: Whether to purge all items when the relevant publisher goes offline 2) That, when talking about a normal purge a purge request MUST NOT result in sending the same notifications as are sent when deleting items (since purging a node with many persisted items could result in a large number of notifications); instead, the node MUST send a single notification to each subscriber, containing an empty purge/ child element. and that's it. So the closest thing I can see to prescribed behaviour is that when doing a purge_offline because a publisher went offline their items are silently removed and that if the node is now completely empty a purge.../ notification is sent. This still doesn't seem entirely satisfying, but the only other option seems to be sending retract notifications for all of the items removed, which (2) says a purge explicitly MUST NOT do. Thoughts? As this feature was added for extended presence, I believe the assumption here is that there is only one publisher: the owner of the PEP node. As such I would interpret this option to mean that the node is purged, i.e. all items are retracted with a single purge/ notification for each subscriber. Retracting only a subset of the items doesn't feel like a purge to me. Maybe this option is not very well suited for the case where there are potentially multiple publishers, as one of them going offline would result in the retraction of items published by others, too. I agree this should be described better. -- ralphm
[Standards] Proposed Patch: Pipelining
Attached is a proposed patch to de-recommend HTTP pipelining, as discussed at the summit. Critiques welcome! /me moves onto 1 sometimes 2 sockets - mm Matthew A. Miller http://goo.gl/LK55L pipelining.patch Description: Binary data
Re: [Standards] XEP-0012: Last Activity's future
On 02/18/2013 09:18 AM, Tobias Markmann wrote: Hi, So currently we have XEP-0012 which we don't like because of the relative time semantic, it uses. In addition that it is currently used for two different purposes: 1. Discover the time a disconnected user last accessed its account (i.e. was online). 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) Note: XEP-0256 seems to do the same as 2) but using presence. I suggest we deprecate XEP-0012 and XEP-0256. 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. 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's why I propose to use a new protocol, like this https://dl.dropbox.com/u/14672346/xmpp/extensions/xep-0256-replace.html . Not to forget the suggested security notice, suggested by Matt, to Date and Time Profiles on possible geo privacy leak. Opinions? Feedback? Cheers, Tobi +1 I had been drafting almost this exact spec in my spare time, but happy for someone to actually get it done.
Re: [Standards] XEP-0012: Last Activity's future
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
Re: [Standards] PEP - Public PubSub subscribed list
On 15/02/2013 22:42, Dave Cridland d...@cridland.net wrote: Yes, but jid and node, please. Might not be a server as such. Very good point :) iq type='set' from='rainbowd...@mlp.net' id='sub123' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='urn:xmpp:pubsub:subscription' item id=2SjNoqvGNLLXv+6w+4+mbEZ subscription xmlns='urn:xmpp:pubsub:subscription:0' jid='pubsub.etu.univ-nantes.fr http://pubsub.etu.univ-nantes.fr/ ' node='mlp' titleMy Little Pony - Fan Club/title /subscription /item ... /publish /pubsub /iq -- Ash
