Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread Christian Schudt
I like Florian’s idea! It won’t mess up with existing XEP-0256 implementations and if someone really feels he can only deal with absolute timestamps he could use that optional attribute. It’s way easier to implement as opposed to implement a whole new XEP (+ abstraction layer, which deals with

[Standards] Which XEP can I use to solve this use case?

2014-12-03 Thread priya v
Hi all, If I need to implement a functionality (in an XMPP client and in an XMPP server) whereby I indicate to a user if a message sent by him to another user has been read/delivered/acknowledged, which XEP should I be implementing? Additionally, I want the status of the messages to be synced acro

[Standards] Chat markers and pagination

2014-12-03 Thread priya v
How would chat markers work when they are used in the context of pagination? Please consider the following use case to get a better understanding of my question- Assume there are 50 messages stored in a user's archive store. Of which a marker of type 'delivered' is received for the 25th message. A

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread Dave Cridland
On 3 December 2014 at 23:14, Florian Schmaus wrote: > BTW was it ever discussed to *simply* extend XEP-12 (and thus XEP-256) > with an (optional) 'timestamp' attribute that contains an absolute time > value? > I'd particularly like to see any response to this. It looks like a very reasonable ave

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread Florian Schmaus
On 03.12.2014 23:39, Florian Schmaus wrote: > On 03.12.2014 19:16, XMPP Extensions Editor wrote: >> This message constitutes notice of a Last Call for comments on XEP-0319 >> (Last User Interaction in Presence). >> >> Abstract: This specification defines a way to communicate time of last user >>

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread Florian Schmaus
On 03.12.2014 19:16, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0319 (Last > User Interaction in Presence). > > Abstract: This specification defines a way to communicate time of last user > interaction with her system using XMPP presence no

[Standards] XEP 313 error handling

2014-12-03 Thread Kurt Zeilenga
How does the server, after it has responded to the IQ with a type=result stanza, communicate errors in processing the query to the client that might subsequently occur. What if the server is unable to send any subsequent stanzas associated with the query? Is the server expected to hold off se

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread Tobias Markmann
Hi, Some comments from the author’s perspective inline. On 03.12.2014, at 19:16, XMPP Extensions Editor wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? It fills a gap for a clean and reliable reporting of idle (user inacti

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread Christian Schudt
Hi, here’s my feedback for it. > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? No. In my opinion, XEP-0256: Last Activity in Presence already covers everything, which is needed for this use case. XEP-0012 also says something abou

[Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

2014-12-03 Thread XMPP Extensions Editor
This message constitutes notice of a Last Call for comments on XEP-0319 (Last User Interaction in Presence). Abstract: This specification defines a way to communicate time of last user interaction with her system using XMPP presence notifications. URL: http://xmpp.org/extensions/xep-0319.html

Re: [Standards] Proposed XMPP Extension: namespace delegation

2014-12-03 Thread Sergey Dobrov
On 11/27/2014 03:34 PM, Goffi wrote: > Hi Sergey, > >> * server will have to refuse stanzas with these namespaces when >> component is down by some reason, so the namespace lease is permanent >> and does not need any negotiation > > That's a good point, actually the bahaviour is not specified w