Logs for jdev@conference.jabber.org
[00:11:43] * Maranda joined the chat.
[00:46:11] * Maranda left the chat.
[00:51:43] * Maranda joined the chat.
[00:54:42] <> ralphm, that behaviour could be caused because Cisco's jabberd doesn't reuse the stream it verifies dialback on btw.
[00:57:09] <> so when the incoming or outgoing streams fails your side the remaining gets thrown, bbl.
[01:04:20] * Zash left the chat.
[01:15:52] * Florob left the chat.
[01:16:11] * edwinm left the chat.
[01:19:41] * edwinm joined the chat.
[01:19:51] * Lance left the chat.
[01:26:19] * waqas left the chat.
[01:42:24] * Maranda left the chat.
[02:00:14] * tato joined the chat.
[02:05:35] * tato left the chat.
[02:05:58] * tato joined the chat.
[02:44:02] * bear left the chat.
[02:49:32] * waqas joined the chat.
[02:56:18] * Lance joined the chat.
[03:04:19] * tato left the chat.
[03:27:39] * Tobias joined the chat.
[03:33:30] * Tobias left the chat.
[03:52:39] * edwinm left the chat.
[03:56:02] * bear joined the chat.
[03:59:46] * edwinm joined the chat.
[04:17:13] * bear left the chat.
[04:43:05] * aRyo left the chat.
[05:41:57] * waqas left the chat.
[06:08:04] * Asterix joined the chat.
[06:18:01] * Asterix left the chat.
[07:35:54] * ermine joined the chat.
[07:38:28] * Tobias left the chat.
[07:50:24] * edhelas joined the chat.
[07:51:23] * bear joined the chat.
[08:04:01] * 0xAFFE joined the chat.
[08:17:58] * Tobias joined the chat.
[08:18:22] * bear left the chat.
[08:29:46] * Flow joined the chat.
[08:31:34] * ralphm left the chat.
[08:38:38] * kevin joined the chat.
[08:39:30] * kevin left the chat.
[08:39:35] * kevin joined the chat.
[08:52:02] * KevWalke joined the chat.
[08:52:16] * turing joined the chat.
[08:55:54] * Alex joined the chat.
[09:53:45] * Kev joined the chat.
[10:01:19] * edhelas left the chat.
[10:01:51] * KevWalke left the chat.
[10:03:51] * kevin left the chat.
[10:26:51] * Flow left the chat.
[10:42:32] * Lloyd joined the chat.
[11:11:35] * Lance left the chat.
[11:18:28] * ralphm joined the chat.
[11:22:25] * ralphm left the chat.
[11:22:54] * ralphm joined the chat.
[11:30:58] <> Hi
[11:31:11] <> hi turing
[11:31:32] <> Is it normal that Prosody server can send me an <iq> without a from attribute?
[11:32:36] <> Seems like the rfc says the receiving entity MUST send it (§4.4), but my english is not so good to be sure...
[11:33:34] <> 4.4 of 6120 is talking about closing streams, and 4.4 of 6121 is talking about presence broadcasts. Which RFC do you mean?
:)
[11:43:18] <> I looked at http://xmpp.org/rfcs/rfc3920.html
[11:43:53] <> 6120 is the current version of xmpp-core.
[11:44:01] <> so s/3920/6120/ s/3921/6121/
[11:44:51] <> ok thank you for pointing this mistake
[11:45:02] <> So it's 4.7.1 §
[11:45:25] <> That's talking about the stream headers.
[11:45:46] <> I'm using BOSH
[11:46:00] <> That doesn't change that it's talking about the stream headers.
[11:46:32] <> What you want is 8.1.2.1, I think.
[11:46:45] <> So I think it's not related to my problem
[11:46:55] <> Which says that it's legal to send you stanzas without a from.
[11:47:08] <> I'll dig a bit more, sorry for that
[11:48:08] <> In general, if a client sends a stanza without a to, it means it's going to the bare JID, and if it receives without a from
it's coming from the bare JID.
[11:48:15] <> (where bare JID is handled by the server)
[11:48:37] <> So it comes from it's own bare jid?
[11:48:44] <> Yes.
[11:49:13] <> To be clear, my client send an iq <list name='ignore'/>
And the server answers a <error type='cancel'><service-unavailable>
[11:49:49] <> But in the answer, the <iq> element has no from; So I should consider it comes from my own bare JID? It does not seem legit
[11:50:14] <> Yes. No from and from=yourBareJID are equivalent.
[11:51:02] <> Ok, so it's normal that this kind of answer have from= my bare jid
[11:51:26] <> Thank you! So Stanza.js has a bug. It does not handle this case.
[11:51:57] <> *Strophe.js
[12:36:14] * Flow joined the chat.
[12:45:25] * Irdis left the chat.
[13:56:35] * Lance joined the chat.
[14:07:26] * aman joined the chat.
[14:23:10] * stpeter joined the chat.
[14:24:23] * ralphm left the chat.
[14:24:43] * aman left the chat.
[14:35:34] * stpeter left the chat.
[14:46:39] * aman joined the chat.
[14:56:29] * turing left the chat.
[14:58:31] * turing joined the chat.
[15:46:12] * stpeter joined the chat.
[15:46:32] <> Kev: hm, I expected an empty 'from' to mean the session's full JID (after resource binding)
[15:46:51] <> ralphm: It's never meant that, AFAIK.
[15:47:50] * ralphm joined the chat.
[15:47:59] <> Kev: while that might be so, it doesn't change my expectation
[15:49:05] <> :)
[15:51:42] * ralphm left the chat.
[15:54:50] <> Kev: among other things, because it means that you can send an iq that you can't get the response for back in your stream
[15:55:13] <> Hmm?
[15:55:38] <> You'll always get it back on the same stream, you only have one stream.
[15:55:45] <> Where else can it go? :)
[15:56:51] * waqas joined the chat.
[15:58:33] <> Kev: if I send <iq to='muc.xmpp.org' id='p1' type='get'><query xmlns="jabber:iq:version"/></iq> from my client
[15:58:53] <> Kev: you are saying that it gets a from of 'ralphm@ik.nu'
[15:59:18] <> Kev: why would the server send a response to that query to my resource?
[16:00:46] <> No.
[16:01:01] <> This is stanzas that the server sends to a client.
[16:01:09] <> Not that the client sends to a server.
[16:01:36] <> ok, that makes more sense indeed
[16:19:32] * Florob joined the chat.
[16:24:37] * deryni left the chat.
[16:24:49] * deryni joined the chat.
[16:43:44] * 0xAFFE left the chat.
[16:44:27] * Lance joined the chat.
[16:52:43] * Lance joined the chat.
[16:54:50] * Lance left the chat.
[16:56:48] * jcea joined the chat.
[16:58:10] * Lloyd left the chat.
[17:02:56] * Lance left the chat.
[17:15:48] <> Me again :)
[17:16:41] <> My client sent a <iq from='bob@localhost/Candy' to='so@chat.candychat.local/bob' type='get' xmlns='jabber:client' id='5294:sendIQ'>
(a disco#info)
And the server respond <iq xmlns='jabber:client' type='get' to='bob@localhost/Candy' from='so@chat.candychat.local/bob' id='5294:sendIQ'>
[17:18:18] <> RFC 6120 , § 8.2.3 explicitely says that an iq type="get" MUST be replied with a type="result" or "error"
[17:18:40] <> But here the server (Prosody fyi) respond with another "get".
[17:19:17] <> It isn’t the server, is it?
[17:19:23] <> Looks like another client.
[17:19:24] <> That may make sense since this iq is self-addressed (from my JID to me through a MUC), but it seems to be forbidden by the
protocol
[17:19:48] <> Oh, then you received it and are expected to answer with a type result or error.
[17:20:08] <> And only then you will receive your iq.
[17:21:01] <> If I send an iq with id="5294:sendIQ", I expect the server answer with the same ID is the response, no?
[17:21:30] <> I don't understand you well (sorry for my bad english ;))
[17:21:38] <> You didn’t send your stanza to a server, you sent it to yourself.
[17:21:44] <> So you are expected to answer to it.
[17:22:09] <> Interesting
[17:23:06] <> Looks like Strophe.js has another bug
[17:23:14] <> It does not handle this case.
[17:24:34] <> Well, you simply received an iq get from so@chat.candychat.local/bob, you should just answer to it normally.
[17:24:44] <> You shouldn’t even special case it.
[17:25:25] <> Yes that's legit. But Strophe.js await either a "result" or an "error" when it sends an "iq". It does not handle the case
when the iq is self-addressed...
[17:26:07] <> Yes and no, you expected to get a response with that id, you didn't. Your client needs to understand to process the get, send
a reply and then still expect to get a response to that original get with the same id.
[17:26:10] <> Are you using some kind of synchronous API?
[17:26:59] <> I'm using Strophe.js through BOSH
[17:27:07] <> Strophe isn't synchronous, surely?
[17:27:32] <> It shouldn’t, but perhaps there is a facility API for that (I expect not).
[17:28:04] <> It is asynchronous, but this is important?
[17:28:49] * scippio joined the chat.
[17:29:05] <> If it's async, you should be receiving a signal of some sort saying there's an iq you need to reply to.
[17:29:17] * Flow left the chat.
[17:29:23] * Tobias left the chat.
[17:29:43] <> Yes, absolutely. I understood the solution. I just need to fix Strophe, again :D
[17:30:15] <> ...or to give up :(
[17:30:17] <> Does this violate id uniqueness rules? (Unavoidably I understand but does it?)
[17:30:42] <> deryni: I don't think so, no.
[17:30:49] <> Because the id uniqueness rules are between two entities.
[17:30:50] <> That's a good question, because in such case I will send two iq with the same ID
[17:31:27] <> send iq#42 get ; recv iq#42 get ; send iq#42 result <=== here :s
[17:31:31] <> Wouldn't the two entities be yourself in this case? Or do you mean it is directional as well (incoming vs. outgoing)?
[17:32:01] <> So A sends to B (MUC of A) with an id. B sends to A with the same id - different endpoints so it's fine. A replies with a
result to B, B replies with result to A.
[17:32:29] <> deryni: I think it's directional, yes. Although whether this is consistent with the spec I have no idea offhand.
[17:32:48] <> But you have no way of preventing A and B using the same id at the same time in an asynchronous system.
[17:33:28] <> For your information, I only have one client here. A and B are the same client (Strophe.js not to mention)
[17:33:45] <> You have B, which is the MUC mirror of your JID.
[17:33:52] <> So the spec says generating IDs (and the associated uniqueness rules) are an issue for the "originating entity" and defines
"originating entity" as the "entity that first generates a stanza that is sent over an XMPP network".
[17:34:17] <> So this is fine, then.
[17:34:24] <> Yes?
[17:34:36] <> yes for the mirror
[17:35:08] <> So I should associate the originating entity (A or B) to the ID. And this is the pair (A, iq id) that must be unique?
[17:35:13] <> I think so. The MUC needs to rewrite to/from on the stanza at least it sends so that's probably originating for this purpose.
[17:35:28] <> s/(at least) (it sends)/\2 \1/
[17:36:36] <> The uniqueness bit of this issue was the least practically interesting part. Just an idle question. The practical issue is
that an incoming get doesn't match up to a pending outgoing get (even when the id:s match).
[17:37:05] <> So if strophe is checking the iq first and then handling that as a response regardless that would seem to be the issue.
[17:38:05] <> Thats the case. I must fix it
[17:38:10] <> It would be very easy for a library to have bugs in this area.
[17:38:43] <> The only problem is that it considers the get answer as an error
[17:38:54] * aman left the chat.
[17:39:09] <> Instead it should ignore it on this specific case, right?
[17:39:19] <> It should respond to it like any other incoming iq get.
[17:39:31] <> It shouldn't trigger the pending outgoing iq-get response code at all.
[17:39:51] <> yes absolutely
[17:40:00] <> Thank you for this clarification!
[17:40:10] <> And yeah, I'm sort of tempted to go look and see how libpurple handles this but I'm afraid to go check right now. =)
[17:40:24] <> ^^
[17:40:49] <> deryni: Even Swiften had an bug in iq:result handling at one point.
[17:41:49] <> (If the client sent to the server with a bareJID to, and the server decided to remove the from, maybe? Something like that)
[17:46:20] <> Yeah. I wouldn't at all be surprised if this case didn't work right in libpurple I just prefer my cat unobserved for the moment.
[17:47:58] <> So I better should avoid the client issuing this kind of self-addressed iq?
[17:48:10] <> turing: I'm not sure what you need it for.
[17:48:22] <> Or, rather, I can't think of any reason for you wanting to send it.
[17:48:26] <> I either dont know ^^
[17:50:10] <> Other than as a test for what the MUC does to routed iq stanzas I can't think of anything.
[17:50:32] <> And, offhand, I can't think of a reason to need to test that.
[17:50:43] <> Since I will only use non-anonymous MUC, that should not be the case anymore
[17:51:03] <> I don't think the MUC being anonymous makes any difference here.
[17:51:49] <> I often send an iq version on myself to know when was the last time I compiled my client.
[17:51:54] <> If its not anonymous, I will see my own JID, so I can avoid sending an iq to myself easily
[17:51:55] <> So I can see an use for that.
[17:52:18] <> You send a query from your own client, through a MUC, back to your own client, to ask the version of your client?
[17:52:26] <> Yeah.
[17:52:32] <> This rather suggests a failing in the 'about' result of your client :p
[17:52:39] <> Of course. ^^
[17:52:51] <> But it has never bothered me enough to add it.
[17:53:22] <> My plan is to allow two clients (or more) to be able to connect to a MUC, and appearing as 1 user on the MUC. And after that,
I'll use Carbon Copy to keep all clients in sync. In short : make XMPP client-agnostic (all clients see and are seen as one)
[17:54:00] <> Alright, bug reported about the /self command.
[17:54:17] <> Link Mauve: :)
[17:54:46] <> I like the help. ^^
Help> Usage: /self
Remind you of who you are.
[17:56:43] <> “18:51:50 turing> If its not anonymous, I will see my own JID, so I can avoid sending an iq to myself easily”, you already
know who you are, the MUC sends you back your nick.
[17:56:53] <> Even when the room is anonymous.
[17:57:30] <> Interesting, so there is no reason the client send a disco#info to myself....
[17:57:45] <> No, you already know who you are.
[17:58:00] <> The client is Candychat fyi, and it's a goood piece of crap
[17:58:33] <> But I didn't find a better alternative to make a web client
[17:59:55] <> turing, it’s the status 110 that indicates that a presence refers to yourself.
[18:00:15] <> As defined section 15.6.2 of XEP-0045.
[18:00:20] * Tobias joined the chat.
[18:00:27] <> Thank you for this information :)
[18:00:49] <> :)
[18:19:44] * stpeter left the chat.
[18:52:05] * kevin. joined the chat.
[19:14:28] * MattJ left the chat.
[19:23:18] * ermine left the chat.
[19:27:34] * Lance joined the chat.
[19:37:19] * Lance left the chat.
[19:38:00] * jcea left the chat.
[19:43:16] * Maranda joined the chat.
[19:47:15] * Florob left the chat.
[19:47:16] * Florob joined the chat.
[20:05:28] * stpeter joined the chat.
[20:06:59] * sezuan joined the chat.
[20:07:30] * stpeter left the chat.
[20:07:40] * stpeter joined the chat.
[20:26:52] * Florob left the chat.
[20:26:55] * Florob joined the chat.
[20:27:25] * kevin. left the chat.
[20:32:15] * Florob left the chat.
[20:32:17] * Florob joined the chat.
[20:32:54] * Lance left the chat.
[20:37:35] * Lance joined the chat.
[20:41:44] * MattJ joined the chat.
[21:02:00] * stpeter left the chat.
[21:06:31] * sezuan left the chat.
[21:06:44] * sezuan joined the chat.
[21:10:37] * sezuan left the chat.
[21:10:51] * sezuan joined the chat.
[21:11:04] * sezuan left the chat.
[21:20:29] * Alex left the chat.
[21:26:26] * Alex joined the chat.
[21:28:35] * Zash joined the chat.
[21:30:24] * Zash left the chat.
[21:35:14] * Tobias joined the chat.
[21:39:06] * Alex left the chat.
[21:39:31] * Tobias left the chat.
[21:41:26] * Tobias left the chat.
[21:48:41] * Lloyd joined the chat.
[22:05:15] * 0xAFFE joined the chat.
[22:05:34] * Tobias joined the chat.
[22:15:35] * turing left the chat.
[22:17:40] * Tobias joined the chat.
[22:19:26] * Tobias left the chat.
[22:28:26] * Florob left the chat.
[22:37:08] * Maranda joined the chat.
[22:37:21] * Maranda left the chat.
[22:41:29] * Lloyd left the chat.
[22:57:52] * tato joined the chat.
[23:05:34] * 0xAFFE left the chat.
[23:05:37] * KevWalke joined the chat.
[23:10:05] * Florob joined the chat.
[23:17:10] * Lance left the chat.
[23:21:06] * jcea joined the chat.
[23:31:49] * tato left the chat.
[23:31:50] * tato joined the chat.
[23:44:56] * Tobias left the chat.
[23:51:45] * Tobias joined the chat.
[23:58:38] * Florob left the chat.