Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
On Tue Apr 14 09:41:28 2009, Jiří Zárevúcký wrote: 2009/4/14 Dave Cridland d...@cridland.net: On Mon Apr 13 18:18:39 2009, Jiří Zárevúcký wrote: Am I right? Yes, you are, well spotted. Actually, I'm not. My reasoning would require that the items themselves are partial, which they are not. So the push includes the complete last known state of the item, not a change. Ah, yes - your reasoning would alternately mean that a single change could encompass more than one roster item, which it also cannot (and if it could, the solution would be different). I shouldn't reply to these things so late at night. That means there is no such problem, as even though the client is not guaranteed to have a complete state on failure, it will have it when it resumes receiving from the point it left of. Yes. So we're both wrong - yay! But thanks for looking into this carefully. That also means this part can be somewhat misleading: 4. The interim roster pushes would not include all of the intermediate steps, only the final result of all changes applied while the client was in fact offline. .. as it suggests that the changes (to a single item) combine, while in fact they replace each other. I'm not sure they replace, as such - collapse might be a better word. Changing both subscription state, and, later, changing name, results in a single roster push containing both changes. However, changing name twice will effectively replace. I think an example speaks a thousand words, here - since you've a feel for this, could you write one? (I'm sure Peter would appreciate it). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] XEP-0224 Attention
2009/4/14 Jiří Zárevúcký zarevucky.j...@gmail.com: 2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: In 3rd bullet point of section 4, http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well receive a delayed 'attention', though I propose the change from MUST to SHOULD. That's nonsense. When user receives your delayed attention request, you could very well be in work, school, with girlfriend, etc by then. Attention is a way to get him to talk to you immediately. Not so nonsense: I wish I had the passed attention requests when I get back to my client... It is a worthwhile information, even if it's too late. That way, I could contact back the guy that tried to get my attention. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] XEP-0224 Attention
On Tue, Apr 14, 2009 at 10:40 AM, Nicolas Vérité nicolas.ver...@gmail.com wrote: Not so nonsense: I wish I had the passed attention requests when I get back to my client... It is a worthwhile information, even if it's too late. That way, I could contact back the guy that tried to get my attention. Damn - if only we had some sort of messaging system we could use for this... /K
Re: [Standards] XEP-0224 Attention
2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: 2009/4/14 Jiří Zárevúcký zarevucky.j...@gmail.com: 2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: In 3rd bullet point of section 4, http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well receive a delayed 'attention', though I propose the change from MUST to SHOULD. That's nonsense. When user receives your delayed attention request, you could very well be in work, school, with girlfriend, etc by then. Attention is a way to get him to talk to you immediately. Not so nonsense: I wish I had the passed attention requests when I get back to my client... It is a worthwhile information, even if it's too late. That way, I could contact back the guy that tried to get my attention. You won't generally try an attention to someone you haven't send several classic messages already and didn't get response... That would be considered rude and maybe even spamming.
Re: [Standards] XEP-0224 Attention
On 4/14/09 3:44 AM, Jiří Zárevúcký wrote: 2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: 2009/4/14 Jiří Zárevúcký zarevucky.j...@gmail.com: 2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: In 3rd bullet point of section 4, http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well receive a delayed 'attention', though I propose the change from MUST to SHOULD. That's nonsense. When user receives your delayed attention request, you could very well be in work, school, with girlfriend, etc by then. Attention is a way to get him to talk to you immediately. Not so nonsense: I wish I had the passed attention requests when I get back to my client... It is a worthwhile information, even if it's too late. That way, I could contact back the guy that tried to get my attention. You won't generally try an attention to someone you haven't send several classic messages already and didn't get response... That would be considered rude and maybe even spamming. Right. Let's not propose technical solutions to social problems. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0224 Attention
On 4/14/09 3:36 AM, Jiří Zárevúcký wrote: 2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: In 5th bullet point, I propose a change to The attention extension MUST NOT use iq/ stanzas, since use this feature is part of the conversation. No objections against that. There's a typo though, since use *of* this feature (it's in the original text, too). How about this? The attention extension MUST NOT be sent in iq/ stanzas, since use of this feature is part of a messaging conversation. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0224 Attention
On Tue, Apr 14, 2009 at 15:56, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/14/09 3:36 AM, Jiří Zárevúcký wrote: 2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com: In 5th bullet point, I propose a change to The attention extension MUST NOT use iq/ stanzas, since use this feature is part of the conversation. No objections against that. There's a typo though, since use *of* this feature (it's in the original text, too). How about this? The attention extension MUST NOT be sent in iq/ stanzas, since use of this feature is part of a messaging conversation. Better of course, thanks. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
[Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
resend... Original Message Subject: Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning) Date: Tue, 14 Apr 2009 09:15:47 -0600 From: Peter Saint-Andre stpe...@stpeter.im To: XMPP Standards standards@xmpp.org On 4/14/09 3:06 AM, Jiří Zárevúcký wrote: But I realized there is a rare scenario where it could really cause problem. query ver=300 item jid=b...@example.org subscription=none / /query query ver=301 item jid=al...@example.org subscription=none / /query query ver=302 item jid=b...@example.org name=Bob subscription=none / /query query ver=303 item jid=al...@example.org subscription=to / /query query ver=304 item jid=b...@example.org name=Bob subscription=from / /query query ver=305 item jid=b...@example.org name=Bob subscription=none / /query Client knows 300. The roster would send 303 first, and 305 second. If connection failed after sending 303, client would next request 303+, but never received 302 in the first place. There seems to be some confusion about how roster versioning works. Perhaps the spec needs to describe this all in a lot more detail. However, I'll do that here first. Let's say you have two clients, 1 and 2. 1 is up to date as of ver='299' and then goes offline. 2 stays online and completes some roster management tasks. Then 1 comes back online. 1: iq type='get' query xmlns='jabber:iq:roster' /iq S: iq type='result' query xmlns='jabber:iq:roster' ver='299' item jid='ji�...@čechy.cz'/ /query /iq 1: /presence [first roster update from client 2, with Set and Push] 2: iq type='set' query item jid=b...@example.org subscription=none / /query /iq S: iq type='set' query ver=300 item jid=b...@example.org subscription=none / /query /iq [second roster update from client 2, with Set and Push] 2: iq type='set' query item jid=al...@example.org subscription=none / /query /iq S: iq type='set' query ver=301 item jid=al...@example.org subscription=none / /query /iq [third roster update from client 2, with Set and Push] 2: iq type='set' query item jid=b...@example.org name=Bob subscription=none / /query /iq S: iq type='set' query ver=302 item jid=b...@example.org name=Bob subscription=none / /query /iq [Alice approves subscription request from user] S: iq type='set' query ver=303 item jid=al...@example.org subscription=to / /query /iq [client 2 approves subscription request from Bob] S: iq type='set' query ver=304 item jid=b...@example.org name=Bob subscription=from / /query /iq [Bob sends unsubscribe] S: iq type='set' query ver=305 item jid=b...@example.org name=Bob subscription=none / /query /iq Now the user comes back online with client 1. 1: iq type='get' query xmlns='jabber:iq:roster' ver='299'/ /iq So the server needs to send what's changed to client 1. It does this, not by sending 300, 301, 302, 303, 304, and 305, but by sending the effective difference between 299 and 305. First it tells client 1 that there are changes: S: iq type='result' query xmlns='jabber:iq:roster' ver='305'/ /iq That means the latest version is no longer 299 but I'm going to send you the changes as roster pushes -- when you receive a push numbered 305 then you know you're up to date. Now the server sends two roster pushes: one related to Alice (303) and one related to Bob (305): S: iq type='set' query ver=303 item jid=al...@example.org subscription=to / /query /iq S: iq type='set' query ver=305 item jid=b...@example.org name=Bob subscription=none / /query /iq Therefore client 1 knows that it's up to date, and it has received the most recent information about each roster item that was changed while it was offline. You are raising the scenario of the stream dying right after the server sends 303. I'm saying that client 1 MUST NOT consider itself to be up to date when it receives 303, because the server has already told it that the latest version is 305. Therefore, when the client reconnects it MUST behave as if it never received the roster push for version 303 and instead send the exact same roster get it sent when it came back online (i.e., 299). Now (only) in case the server checks the last state client should know, it will find out it doesn't need to send the push since there is the same state as in 302. Client wouldn't receive bob's name until next change. That is easily fixed by disallowing servers such checks. Sure. Perhaps we need an implementation note for servers, which says: basically, you need to keep a record of each roster item that has changed since the last roster get(s) for this account, but you don't need to keep a record of each change, only the last state related to each changed item. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] various rfc3920bis feedback
On 4/13/09 11:59 PM, Philipp Hancke wrote: Peter Saint-Andre wrote: [snip] Now what happens should I attempt to piggyback the users.jabber.org connection on the jabber.org connection? jabber.org kills my stream. Really? Why? host-unknown/. If jabber.org really does host users.jabber.org, why does it return a host-unknown/ error? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] various rfc3920bis feedback
On 4/13/09 11:59 PM, Philipp Hancke wrote: Peter Saint-Andre [snip] * connection reuse for multiple s2s links would be a very useful feature, ask Dave for details Piggybacking. Which is subtly broken in RFC 3920 - at least 50% of it. host-unknown/ makes 'target piggybacking' (different to) unusable, as you risk the entire stream. I'm not so sure about that. host-unknown/ means you're trying to communicate with a domain that I don't host at my server. How does the initiator discover that without running into the error? DNS does not work even in the same domain. I don't follow. What I'd like to do here is use the dialback elements as an authorization request mechanism. Dialback is 50% authorization request, 50% key verification. Splitting it up accordingly simplifies the description. As long as it's backwards-compatible. It is merely a different way of describing it. The protocol already contains this split: db:result (authorization part) db:verify (key verification). Sure, if it helps to describe things that way, then let's update the description. :) In fact, by specifying how to do this without actually doing dialbacks, but instead by verifying the identity of the sender based on the X.509 cert, we can actually get rid of SASL EXTERNAL and just use X.509 only, which eliminates the difference between the first authorization and subsequent ones. There is no 'subsequent' auth with 0178 yet, is there? There is no subsequent auth anywhere, yet. There is piggybacking :-p Dialback is not an authentication protocol. [snip] It's still not clear to me what TLS+dialback really means. If you're going to do TLS, use real certs and then you can do authentication via SASL EXTERNAL. SASL EXTERNAL is a non-starter in the public network. That's an assertion not necessarily backed up by evidence. I am not convinced that TLS + EXTERNAL is a non-starter on the public XMPP network, but then again I help to run a CA that issues free domain certificates for that network (visit http://xmpp.org/ca/ to get yours today). I think we can say that TLS + EXTERNAL has not been widely adopted, but that doesn't mean it never will be widely adopted. It all depends on what threats people perceive. If the costs of getting a domain cert start to be less than the costs of unsecured federation, then people will start to use certificates. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
You are raising the scenario of the stream dying right after the server sends 303. I'm saying that client 1 MUST NOT consider itself to be up to date when it receives 303, because the server has already told it that the latest version is 305. Therefore, when the client reconnects it MUST behave as if it never received the roster push for version 303 and instead send the exact same roster get it sent when it came back online (i.e., 299). Client does not consider itself up-to-date but it would retrieve a complete state if it starts retrieving again from that particular point. So it could save the interim pushes as they arrive (if we disregard the last change to the spec, which was based on wrong assumptions). That could make a huge difference if the client is on very low bandwidth, or expensive connection based on transfered data (which for example GPRS on mobile phones).
Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]
On 4/14/09 12:44 PM, Jiří Zárevúcký wrote: You are raising the scenario of the stream dying right after the server sends 303. I'm saying that client 1 MUST NOT consider itself to be up to date when it receives 303, because the server has already told it that the latest version is 305. Therefore, when the client reconnects it MUST behave as if it never received the roster push for version 303 and instead send the exact same roster get it sent when it came back online (i.e., 299). Client does not consider itself up-to-date but it would retrieve a complete state if it starts retrieving again from that particular point. So it could save the interim pushes as they arrive (if we disregard the last change to the spec, which was based on wrong assumptions). That could make a huge difference if the client is on very low bandwidth, or expensive connection based on transfered data (which for example GPRS on mobile phones). Aha, I see what you are saying. That's possible. I'll need to think about it some more... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] MXM #2
On March 12 and again today, we held a Monthly XMPP Meeting: http://logs.jabber.org/j...@conference.jabber.org/2009-03-12.html#15:01:15 http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#14:06:45 I know it's a bit backwards, but I'm going to report on today's meeting first because it's fresh in my mind (and sorry about not yet publishing minutes from the first meeting). There was no set agenda, but we talked about the following topics: 1. Last Call for XEP-0232 (Software Information) http://xmpp.org/extensions/xep-0232.html http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#14:10:41 Points: - Is this a misuse of service discovery? - Will this make entity capability caches less useful because they will be too large to search easily? - Does it make more sense to publish this information via PEP using the XEP-0092 format? The XMPP Council will vote on XEP-0232 at its next meeting (April 22). More feedback is welcome before then. 2. Last Call for XEP-0237 (Roster Versioning) http://xmpp.org/extensions/xep-0237.html http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#14:23:19 General agreement that this is in good shape. There are still a few edge cases to figure out, especially the empty roster case. 3. Last Calls for the core Jingle specs http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#14:29:52 No real discussion here. Most people seemed to think that these are ready for Draft. 4. Pubsub/PEP implementations http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#14:37:41 Consensus that we need more interop testing among idavoll, ejabberd, Openfire, Tigase, etc. Perhaps make this a focus at the next XMPP Summit. 5. XEP-0198 (Stream Management) http://xmpp.org/extensions/xep-0198.html http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#14:53:43 People like this. Let's go forth and implement. :) 6. Bidirectional s2s http://logs.jabber.org/j...@conference.jabber.org/2009-04-14.html#15:00:34 We decided that we need a dedicated discussion session about s2s fixes and improvements (dialback, multiplexing domains over a given stream via TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus of the next Monthly XMPP Meeting, tentatively scheduled for May 5. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] more candidates for Final?
Back in August 2007, I posted a list of specs that we might want to push to Final status: http://mail.jabber.org/pipermail/standards/2007-August/016477.html Of those, we have advanced the following: XEP-0012: Last Activity XEP-0085: Chat State Notifications XEP-0174: Serverless Messaging Looking over the original list with the benefit of further experience, I think that we might be able to advance some more specs to Final over the next ~6 months. I have in mind the following: XEP-0045: Multi-User Chat XEP-0138: Stream Compression XEP-0199: XMPP Ping The only sticking point I see on these is that we need to define methods for extending XEP-0045, likely using ad-hoc commands. At XMPP Summit #6 in Brussels, Matthew Wild and I said we would work on that, but we have not yet gotten to it. Perhaps we can do that soon. (Another possibility is XEP-0124 and XEP-0206, which define BOSH and our use of it in XMPP.) I will bring this up at the next Council meeting. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
