Re: [Standards] Proposed XMPP Extension: namespace delegation
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 when component is down (actually the server would manage the stanza, which is not desirable). The issue is actually the same in client mode. It's much harder for client mode as if user already started to use internal services and then plugged in another one... OR that external service could implement not all namespaces and then these namespaces will be served by the origin server and it all looks like hell. So you suggest to block the namespace (send an unavailable error) when component is down in admin mode, which is indeed an option, but what ould you do in client mode ? I have no idea how to deal with client mode, unfortunately :( too much caveats I see here and we probably need to make a list of them and discuss on the next summit? * i think it makes it easier to implement at least just admin mode both on component and server side Yes that's the idea, and it's actually written in implementation notes #1. The IQ/ negociation is not complicated, but the behaviour when component is offline is not specified and that's an issue. Your suggestion make sense, but what would you do in client mode ? Let the normal behaviour when no entity manage a namespace ? That would mean a different behaviour in admin and client mode, that's it ? Ideally, when we have a namespace lease for external component, we should return service-unavailable if that external component is down and never fall back to an internal one to prevent mess. We still need to inform component of which namespaces delegations have been granted and we can do it with a simple message stanza containing the namespaces. If we choose to specify namespaces in configuration, that's an option indeed. But first it's important to specify what to do when component is down, thank you for pointing this. As I already mentioned, client mode is a big hell and I would even suggest to avoid implementing it right now, I'd defer it for better times when we get stable implementations of admin mode. Cheers Goffi -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)
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 about idle time: 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). XEP-0256 just transports this idle time via presence. Having absolute time in XEP-0319 (as opposed to relative time in XEP-0256) should not legitimate an extra XEP. Developers would need to implement both anyway, (if they want to have a good software) and libraries would probably need an abstraction layer, which takes care of both XEPs. 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? Only if it becomes draft status. 4. Do you have any security concerns related to this specification? No. 5. Is the specification accurate and clearly written? Yes. Although „set in stone“ might sound a little bit colloquial? Maybe it also could have a note about „xa“ presence. — Christian
Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)
Hi, Some comments from the author’s perspective inline. On 03.12.2014, at 19:16, XMPP Extensions Editor edi...@xmpp.org 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 inactivity) time. While there is XEP-0012 and its presence based distribution enhancement it still has some drawbacks: - Uses relative time. Receiving clients need to calculate absolute time on receive. Due to transmission delays on different C2S/S2S streams other clients are likely to receive the idle information at different times, leading to different absolute times. Using absolute times circumvents this issue. - XEP-0012 is used for two things. The same syntax has overloaded semantic. Sending a last activity request to JID the sender doesn’t know if the time it’s receiving is the idle time or the uptime. Even if you’d detect the semantic difference from the kind of JID, it’d disallow query of uptime for users. 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? It’s implemented in Swift [1]. I wrote this XEP since I was unhappy with XEP-0012 due to reasons stated under 1. 4. Do you have any security concerns related to this specification? None other than those mention in the XEP. 5. Is the specification accurate and clearly written? I hope so. I’m happy for feedback regarding that though. Cheers, Tobias [1] http://swift.im/git/swift/commit/?id=836925a5cdc7017da7fb84416c803e652b48e399
[Standards] XEP 313 error handling
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 sending the IQ response until it is reasonable assured that no subsequent errors will occur? That is, to the time in which has compiled all the stanzas to sends to the client and is ready to put them to XMPP stream? It seems to me that the IQ response really should come last so that the server is able to indicate to the client whether or not is has successfully completed the request or failed. If sent last, then there’s really no need for a separate fin/. If the IQ response is not last, there there really needs to be some method for the server to indicate that it’s not able to provide further results. Anyways, I’ve implemented this, and for now we hold back the IQ response until we get the data from our internal archives and are otherwise ready to respond to the query. This ensures that if we are generally able to provide an error response if any error happens to occur during the processing of the query. — Kurt
Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)
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 notifications. URL: http://xmpp.org/extensions/xep-0319.html This Last Call begins today and shall end at the close of business on 2014-12-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Christian and Tobias already gave good pro and contra arguments. It comes down to: Does the usage of absolute timestamps justify a new XEP? I don't have any practical experience regarding this, but my intuition says: Yes it does. (It appears to me that absolute timestamps should have been used in XEP-12 from the start.) 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? Yes. Even it means abstracting XEP-256 and XEP-319 in the (client) library, which I usually try to avoid. But it's not possible when there are two XEPs used in the wild, that try to solve the same problem. 4. Do you have any security concerns related to this specification? None other than those mention in the XEP. 5. Is the specification accurate and clearly written? It would be nice if there was a section explaining the motivation for this XEP. Readers may wonder what why it's required since we have XEP-256. - Florian
Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)
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 interaction with her system using XMPP presence notifications. URL: http://xmpp.org/extensions/xep-0319.html This Last Call begins today and shall end at the close of business on 2014-12-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Christian and Tobias already gave good pro and contra arguments. It comes down to: Does the usage of absolute timestamps justify a new XEP? 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? Such a change would come with all the advantages XEP-319 provides, but without the disadvantages - to have multiple XEPs for the same goal - to force libraries to abstract that Furthermore adding 'timestamp' would be fully backward compatible, if we say that if it's set, 'seconds' must also exist [1]. It's also easier to implement: I would guess adding one or two LOCs to existing XEP-12/-256 implementations plus the logic that favors timestamp over seconds, compared to implementing a new extension element and the abstraction layer. In XEP-12 terms the timestamp value would mean - the time the user logged out for § 3 - the time the user went idle for § 4 - the time the service was started for § 5 If I'm not overlooking something, I would prefer this solution over XEP-319. - Florian 1: As goody, this means one can calculate the lag of the presence stanza. :)
Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)
On 3 December 2014 at 23:14, Florian Schmaus f...@geekplace.eu 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 avenue to explore, and I don't recall it being raised. XEP-0012 is Final, but the additional of an optional attribute seems acceptable from a procedural point of view, and the technical arguments seem plausible. Dave.
[Standards] Which XEP can I use to solve this use case?
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 across all the resources being used by the user. I was inclined towards using chat markers. But the status of the XEP says 'Deferred'. I look forward to receiving a response from the experts in this forum. Thanks, Priya
Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)
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 both XEPs). On the other hand it would be optional and the seconds“ attribute would be mandatory, which means developers would always check the seconds“ attribute anyway. And if they know the date already there’s no need for them to use the „timestamp“ attribute, because it should hold (nearly) the same data. Yes, there might still be transmission delays, as Tobias pointed out, but I think these are negligible, because they are probably only milliseconds and (human) users are probably only interested in an accuracy of minutes. - Christian Am 04.12.2014 um 01:04 schrieb Dave Cridland d...@cridland.net: On 3 December 2014 at 23:14, Florian Schmaus f...@geekplace.eu 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 avenue to explore, and I don't recall it being raised. XEP-0012 is Final, but the additional of an optional attribute seems acceptable from a procedural point of view, and the technical arguments seem plausible. Dave.
