Wednesday, April 11, 2012
council@muc.xmpp.org
April
Mon Tue Wed Thu Fri Sat Sun
            1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
           
XMPP Council Room | https://xmpp.org/about/xmpp-standards-foundation#council | Room logs: http://logs.xmpp.org/council/ | https://trello.com/b/ww7zWMlI/xmpp-council-agenda

[00:17:37] *** Kooda shows as "away"
[01:39:41] *** Kev has left the room
[01:43:16] *** Kev has joined the room
[01:43:17] *** Kev shows as "away"
[03:17:14] *** MattJ has left the room
[07:43:06] *** Tobias has joined the room
[07:43:08] *** Tobias shows as "online" and his status message is "Available"
[08:40:28] *** Kooda shows as "online"
[09:11:39] *** Neustradamus shows as "away"
[10:00:38] *** Kooda shows as "away" and his status message is "mange"
[10:15:24] *** Kooda shows as "online"
[10:32:25] *** Kev shows as "online"
[11:33:19] *** Tobias has left the room
[11:53:37] *** Tobias has joined the room
[11:53:38] *** Tobias shows as "online" and his status message is "Available"
[12:46:56] *** linuxwolf has joined the room
[13:55:57] *** Tobias has left the room
[14:07:34] <Kev> Meeting with nothing on the agenda in ~55 minutes.
[14:08:31] <linuxwolf> w00t
[14:08:58] *** linuxwolf shows as "away" and his status message is "stuffage"
[14:11:42] *** linuxwolf shows as "online"
[14:18:34] *** MattJ has joined the room
[14:23:35] <MattJ> It took me a long time to work out "Today being Monday, tomorrow being Wednesday"
[14:28:07] *** ralphm has joined the room
[14:28:54] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[14:29:16] <Kev> MattJ: Submitted MAM yet?
[14:30:01] *** MattJ shows as "online"
[14:30:05] <MattJ> Not yet
[14:30:39] <ralphm> MattJ: +1 on stream:error everywhere
[14:31:03] <MattJ> Thanks, good to know I'm not just missing the point of that thread
[14:31:33] <MattJ> You MUST answer <iq> requests, but does that mean we shouldn't send a stream:error if there are any outstanding?
[14:32:13] <Kev> Oh, good question. Yes, I guess it does :)
[14:32:23] <ralphm> In Wokkel I just set up a general handler for that not-stanza-but-still-direct-child-of-the-stream-element-that-does-not-have-a-proper-name
[14:32:46] <linuxwolf> or you treat the stream:error as a "catastrophic failure", like a severed network … d-:
[14:33:59] <ralphm> linuxwolf: I do. In Wokkel, you get a Deferred back when sending out an IQ. If the current stream disconnects, the deferred is fired with an exception to that effect.
[14:34:18] <linuxwolf> /nod … it's what I've done just about everywhere, too
[14:34:22] <ralphm> mostly because you can't know what really happens
[14:34:50] <linuxwolf> if a server's at the point of emitting a stream:error, you have bigger problems than unanswered iq's
[14:38:33] <Kev> I think the order here is actually mandated.
[14:39:11] <Kev> Because the server must be processing the stanzas in order - so if you send <iq/><message><illegal/></message> ther server isn't allowed to process the message (and find there's an error) until it's finished with the iq.
[14:39:25] <Kev> Stream errors for server going down or whatever don't fit into this, I realise.
[14:39:43] <linuxwolf> right
[14:39:54] <ralphm> also http://xmpp.org/rfcs/rfc6121.html#roster-syntax-actions-push
[14:40:04] <linuxwolf> I rarely see the <illegal/>, but definitely see the crash (-:
[14:40:05] *** Tobias has joined the room
[14:40:07] *** Tobias shows as "online" and his status message is "Available"
[14:40:53] <ralphm> … which, in spite of the MUST, still allows for not sending a response
[14:40:57] <linuxwolf> graceful-crash?
[14:41:17] <MattJ> Kev, define "finished" (with the iq)
[14:41:43] <linuxwolf> (-:
[14:41:48] <MattJ> Kev, does handling in order require responding in order?
[14:41:54] <Kev> Of course.
[14:41:58] <ralphm> Of course roster pushes in any new design would be <message/> stanzas
[14:42:06] <Kev> It's not handled until the server has replied.
[14:42:23] <MattJ> Ok, so...
[14:42:25] <linuxwolf> ralphm: everything is pubsub
[14:42:49] <ralphm> linuxwolf: hah, earlier specs for pubsub used IQs for notifications
[14:43:09] <MattJ> Kev, if you send a vcard request to an occupant in a MUC room, the server isn't allowed to process any further stanzas from you until that person's server responds with their vcard?
[14:43:10] <ralphm> linuxwolf: this is one reason I think that's a bad idea
[14:43:24] <linuxwolf> in any new design, we can just do <publish/>, <subscribe/>, and <notify/> as TLS (top-level-stanzas)
[14:43:41] <linuxwolf> "just"
[14:44:20] <ralphm> linuxwolf: I guess we'd just drop '<presence/>' and keep '<message/>' and '<iq/>'.
[14:44:35] <linuxwolf> yeah, pretty much (-:
[14:44:49] <Kev> MattJ: It's not the server that's processing the iq.
[14:45:06] <MattJ> So we can have a stream:error before the iq is responded to?
[14:45:19] <Kev> Yes.
[14:45:22] <MattJ> Good
[14:45:32] <ralphm> Of course
[14:45:41] <Kev> Just not before an iq is responded to by the server.
[14:45:52] <Kev> A roster get or whatever.
[14:46:04] <linuxwolf> s/an iq is/an iq addressed to the server is/ ?
[14:46:14] <Kev> Right.
[14:46:34] <MattJ> I think you're talking about something aside from the main issue
[14:46:47] <Kev> Naturally.
[14:46:47] *** stpeter has joined the room
[14:47:24] <MattJ> My original question was whether you could close a stream with unhandled iqs. We've establised a definite 'yes' for iqs sent to non-server JIDs
[14:47:51] <MattJ> and I see no reason a server must reply to an iq, if it's invalid for example, instead of throwing a stream error
[14:48:00] <ralphm> Kev: are you also saying that responses to iqs to the same entity should come back in order?
[14:48:11] <stpeter> gosh, its seems that I've missed a fun discussion
[14:48:29] <MattJ> and I'm thirdly not convinced (but admittedly on more shaky ground) that iqs must be responded to in order
[14:48:41] <MattJ> because I don't equate "handling" with "responding"
[14:48:42] <linuxwolf> MattJ: I agree
[14:48:53] <ralphm> MattJ: agreed, that seems QUITE problematic, to me.
[14:48:55] <MattJ> stpeter, pre-council meeting :P
[14:48:57] <linuxwolf> especially if dealing with large scale
[14:50:22] *stpeter grumbles about a conference call that someone expected him to be on right now
[14:50:27] <ralphm> I think in-order processing is only about accepting stanzas in order and routing them in the same order as much as possible. Nothing beyond that.
[14:50:47] <ralphm> stpeter: claim atmospheric issues
[14:51:10] <MattJ> or claim it's Tuesday
[14:51:18] <stpeter> damn proprietary Outlook invites
[14:51:19] <linuxwolf> hah
[14:51:51] <linuxwolf> fumso
[14:52:07] <linuxwolf> (f*** u microsoft office!)
[15:02:01] <Kev> Righty.
[15:02:07] <Kev> Shall we have our not-a-meeting, then?
[15:02:09] <Kev> 1) Roll call.
[15:02:10] <Kev> I'm here.
[15:02:13] <linuxwolf> presente
[15:02:18] *stpeter is still on his conference call
[15:02:19] <MattJ> Gift
[15:02:24] <ralphm> hi
[15:02:58] <Kev> Tobias: ?
[15:03:02] <Tobias> kev
[15:03:14] <Tobias> ah..council meeting
[15:03:20] <Tobias> youp..i'm here
[15:03:27] <Kev> Did anyone have anything for the agenda?
[15:03:46] <stpeter> ok my call is done
[15:04:04] <Kev> I'll add GSoC, then
[15:04:06] <Kev> 2) GSoC
[15:04:48] <Kev> The applications are in, thanks to the people who answered my call for mentors and have commented on proposals.
[15:05:16] <Kev> I submitted the slot requests to Google yesterday, based on the applications people volunteered to mentor and the comments on the proposals.
[15:06:06] <Kev> There's still time for people to comment on proposals if they want, but I'd rather they didn't juggle anything about too much, as we're pretty much done at this point (apart from the Jitsi guys deciding which proposals they want to accept - but they've chosen a number).
[15:06:24] <Tobias> ok
[15:06:25] <Kev> That's about it.
[15:06:28] <linuxwolf> nice
[15:06:43] <Kev> We've asked for more slots than is usual for us, so I'm expecting Carol not to be able to hand them all over, but hey ho.
[15:07:01] <linuxwolf> (-:
[15:07:17] <stpeter> Kev: would you be so kind as to point me to the message on the GSoC list that says exactly where we complete certain tasks? or is it all somewhere at google.com and I just need to log in someplace?
[15:07:22] <Kev> When that happens I'll look at the comments and scores people have left on the proposals and try to pick the ones we select somewhat fairly.
[15:07:30] <Kev> google-melange.com
[15:07:34] <stpeter> ah ok
[15:07:38] <stpeter> thanks
[15:07:50] <Kev> I think that's everything GSoCcish.
[15:07:59] <Kev> 3) Date of next meeting.
[15:08:11] <Kev> SBTSBC
[15:08:12] <Kev> ?
[15:08:16] <linuxwolf> wfm
[15:08:24] <linuxwolf> hopefully MAM will be a topic of discussion
[15:08:27] <linuxwolf> /zing
[15:08:49] <Kev> We can but hope. Nearly 50% of the XSF's GSoC applications were to work on MAM support.
[15:09:08] <stpeter> heh
[15:09:29] <Kev> Right, SBTSBC it is.
[15:09:31] <Kev> 4) AOB?
[15:09:42] <ralphm> nope
[15:09:47] <linuxwolf> nada
[15:10:09] <MattJ> None
[15:10:13] <Tobias> nope
[15:10:28] <Kev> Sounds good then.
[15:10:31] <stpeter> ok thanks guys, I'm slowly getting back into mostly-xmpp mode, so I'll start working on things of interest here again soon
[15:10:31] <Kev> Thanks all.
[15:10:35] *Kev bangs the gavel.
[15:10:37] <ralphm> Kev: I'm still interested in your responses to the pre-meeting discussion
[15:10:49] <Kev> ralphm: Interested in what way?
[15:11:08] *stpeter closes his computer and heads to the light rail station
[15:11:10] <ralphm> Kev: well, for example, the question I asked
[15:11:22] <Kev> That's not entirely unambigous at this point :p
[15:11:24] <Kev> stpeter: Enjoy.
[15:11:31] *** stpeter has left the room
[15:11:32] *linuxwolf goes for caffeine
[15:11:57] <ralphm> ralphm: Kev: are you also saying that responses to iqs to the same entity should come back in order?
[15:12:33] *** linuxwolf shows as "away" and his status message is "stuffage"
[15:12:37] <ralphm> (and the stuff following that)
[15:13:03] <Kev> Yes.
[15:13:33] <Kev> The entity is obliged to process them in order, their server is obliged to send them to your server in order, and your server is obliged to send them to you in order.
[15:13:58] <ralphm> Kev: I'll rephrase
[15:14:22] <ralphm> Kev: are you saying that responses to iqs should come back in the same order as the requests?
[15:14:37] <Kev> To a given bare JID? Yes.
[15:15:02] <ralphm> As I said before, that seems problematic.
[15:16:05] <Kev> I don't see why.
[15:16:13] <Kev> It's what 6120 says you need to do.
[15:16:26] <ralphm> If I send an IQ to an entity that then goes out to request a web resource to produce a response, and I send it another unrelated IQ that can be responded to immediately, that is really an issue.
[15:16:48] <Kev> The second iq must be pipelined until the first is processed.
[15:17:51] <ralphm> I'm not sure if I agree this is what RFC 6120 says, but I do think it is stupid
[15:18:25] <ralphm> and I don't see why you'd want that kind of behaviour
[15:19:52] <Kev> Interesting, I'm wrong, I think.
[15:20:00] <Kev> What I say only holds true if the entity is a server.
[15:20:14] <ralphm> Really? Also, define 'server'
[15:20:15] <Kev> If it's a client, there seems to be no restriction on the processing order of data it receives.
[15:20:53] <Kev> "Thing at the S end of a C2S link, or at the end of an S2S link"
[15:21:05] <ralphm> also, 'processing' is rather vague
[15:21:39] <ralphm> you also mentioned MUC as an example
[15:21:46] <Kev> Did I?
[15:22:13] <ralphm> Oh, no MattJ did
[15:22:33] *** linuxwolf shows as "away" and his status message is "stuffage"
[15:22:40] <ralphm> He mentioned waiting for the response to an vcard request
[15:23:50] <ralphm> a MUC will send this request on to the actual occupant. Do all groupchat messages have to be queued until the response can be sent back?
[15:24:13] <ralphm> (for the requesting occupant)
[15:24:26] <Kev> That's a fun question.
[15:25:06] <ralphm> RFC 6120 says:
[15:25:12] <ralphm> If the server's processing of a particular request could have an effect on its processing of subsequent data it might receive over that input stream (e.g., enforcement of communication policies), it MUST suspend processing of subsequent data until it has processed the request.
[15:25:38] <ralphm> I believe that the 'if' is rather (intentionally) vague, and not as strict as you seem to make it out to be.
[15:26:10] <Kev> Right.
[15:26:19] <ralphm> e.g. I'd say it does apply for subsequent publish requests to the same node
[15:26:36] <Kev> It seems that the following cases are strictly linear:
[15:26:37] <ralphm> but not to different nodes, or any other unrelated iq or message
[15:27:02] <Kev> Sending anything to your bare JID
Routing stanzas
Receiving routed stanzas
[15:27:20] <Kev> And that for other requests it's vague.
[15:27:29] <Kev> Oh, no, I'm wrong.
[15:27:43] <Kev> To your bare JID or to the server itself.
[15:28:20] <ralphm> so that's all about delivery
[15:28:40] <ralphm> and I agree with *that*
[15:28:44] <Kev> So routing must always be in order, and processing must always be in order if it's your own server - but other entities can process in their own chosen way, subject to the note about subsequent data.
[15:30:20] <ralphm> I still don't want my server to not respond to an iq:version if it is still figuring out what my roster is if the order of requests is 1) roster 2) version
[15:30:35] <Kev> That much is entirely clear in 6120
[15:30:44] <Kev> It must process those requests in order.
[15:30:56] <MattJ> Process, or respond?
[15:31:02] <ralphm> what MattJ says
[15:31:11] <ralphm> this is crucial
[15:31:16] <ralphm> and not clear at all to me
[15:31:19] <Kev> They're one and the same.
[15:31:25] <MattJ> and if this is ambiguous, I think it should be made clear that handle/process != respond
[15:31:36] <ralphm> Kev: I strongly disagree
[15:31:47] <ralphm> Kev: and I don't see any text to support that
[15:32:11] <Kev> If I say "please get me my roster", you can't possibly claim to have completed processing of that request until you have given me my roster.
[15:32:43] *** linuxwolf shows as "away" and his status message is "stuffage"
[15:32:50] *** linuxwolf shows as "online"
[15:33:00] <ralphm> Sure I can!
[15:33:06] <ralphm> If I set my mind to it.
[15:34:35] <ralphm> Kev: also, I am not sure that RFC 6120, section 10.1, shares your interpretation of 'processing' in this case.
[15:34:53] <ralphm> It does not talk about processing requests, but rather processing of stanzas.
[15:35:40] <Kev> "e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM]"
[15:35:47] <Kev> I'd say that was pretty unambiguous.
[15:36:47] <ralphm> I think that's because of the paragraph I pasted. So a business rule for this particular exchange of different related stanzas.
[15:37:09] <ralphm> So I agree on that example, but not on the general case.
[15:37:26] <Kev> But when taken with the complete bullet:
"Stanzas sent by a client to its server or to its own bare JID for direct processing by the server (e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM])."
[15:37:34] <ralphm> there is no reason to delay responding to an iq:version request if you sent out a roster request before that
[15:37:38] <Kev> It is clear that's just an example of the general case to which this rule applies.
[15:39:02] <ralphm> Kev: so if the current text divides us in interpretation, what do you think about what I say in reality? I'd be more than happy to suggest we amend this.
[15:39:17] <Kev> I think this is a good rule.
[15:39:56] <ralphm> I think it is a nightmare.
[15:40:10] <Kev> I think it's possible to find cases where it doesn't serve a purpose (as in your example), but I don't think it's harmful, and I think it's much simpler than trying to create a list of all requests that must be processed in order, which requests they must be processed in order with and which can pass through, etc.
[15:40:59] <Kev> ralphm: In your particular example it's really easy for the client to just request the version first, if response to that is more urgent than getting its roster :)
[15:41:28] <ralphm> Kev: seriously?
[15:42:46] <ralphm> Kev: so an entity should guess how much time it takes for a server to respond to unrelated queries and order them accordingly before sending them out?
[15:43:13] <Kev> No, not really, because just about all queries a client sends to a server it's going to get responses to ~instantly anyway.
[15:43:56] <Kev> Typically how many requests does a client make of its server? Roster, private, vcard, version maybe? These are all going to get processed quickly.
[15:44:11] <Kev> And for heavy processing platforms (i.e. not the clients own server), these rules don't apply.
[15:44:16] <ralphm> I'm talking about XMPP Core, not necessarily about XMPP IM. So while such behaviour might be ok for IM clients, I'd certainly don't want to have such a thing anywhere that generic.
[15:44:27] <linuxwolf> Kev: disco
[15:44:42] <Kev> linuxwolf: Disco should return instantly too.
[15:44:55] <Kev> Unless you were just adding it to the list, rather than a counterpoint, in which case...right.
[15:45:03] <linuxwolf> this "instantly" is a big assumption, IMO
[15:45:15] <linuxwolf> and I was adding to the list
[15:45:15] <Kev> disco#items to a MUC service, on the other hand, isn't subject to these rules.
[15:45:36] <ralphm> Kev: I'm willing to bet that most server developers strongly disagree with your stance on this.
[15:45:49] <linuxwolf> they do
[15:46:05] <ralphm> Kev: also, a muc service could be part of the server you are talking to. I.e. council@xmpp.org *and* ralphm@xmpp.org.
[15:46:37] <Kev> ralphm: It could, this is true.
[15:47:09] <linuxwolf> in any case, if you want to be reasonably sure things are fully handled in the proper order, you wait for the previous iq before sending the next
[15:47:21] <linuxwolf> and that is something we ought to recommend somewhere anyway
[15:47:28] <Kev> linuxwolf: Well, no, you don't need to, because 6120 says it'll do it for you.
[15:47:48] <linuxwolf> Kev: as this discussion points out, your stance is not universally accepted
[15:47:57] <ralphm> linuxwolf: so that's really a business rule of particular exchanges, not of all message/iq processing, right?
[15:48:00] <linuxwolf> processing is a vague term
[15:48:29] <linuxwolf> ralphm: true, but at least for my experiences, it's true far more often than it's false
[15:49:25] <ralphm> linuxwolf: but individually, per types of exchanges (say presence/roster v.s. iq version v.s. pubsub publish)
[15:49:42] <ralphm> linuxwolf: not on all incoming messages/iqs
[15:49:43] <linuxwolf> ralphm: true
[15:49:48] <Kev> linuxwolf: It's not vague, at least for iqs it's fairly clearly defined.
[15:50:02] <Kev> And it includes sending the response.
[15:50:10] <ralphm> Kev: if people disagree with an interpretation (in general) it is not clearly defined
[15:50:12] <linuxwolf> ralphm: it comes down to what's important to "ensure" is handled
[15:50:44] <Kev> I don't see how you can possibly interprep 6120 to not think iq processing includes sending the result.
[15:50:59] <ralphm> Kev: see above.
[15:51:15] <Kev> ralphm: Which part of the text makes you think it doesn't include the return?
[15:51:24] <Kev> "in general the server will respond to the IQ stanza"
[15:52:01] <linuxwolf> Kev: I don't think processing means it has to be completed; it has to be started in the received order, but not necessarily finished
[15:52:18] <linuxwolf> which therefore means it doesn't necessarily have to respond in the received order
[15:54:08] <ralphm> Kev: the part that says "If the server's processing of a particular request could have an effect on its processing of subsequent data it might receive over that input stream"
[15:54:20] <ralphm> Kev: which for my example is false.
[15:54:38] <Kev> ralphm: Yes, that is for stanzas that don't fall under the previous list.
[15:55:10] <ralphm> Kev: not in my world
[15:55:54] <Kev> "In-order processing applies (a) to any XML elements used to negotiate and manage XML streams, and (b) to all uses of XML stanzas"
[15:55:59] <Kev> That really doesn't seem ambiguous.
[15:56:16] <ralphm> as long as you talk about stanzas, it is about delivery
[15:56:24] <ralphm> in my opinion
[15:56:51] <Kev> And to make sure people don't make that mistake while reading it, it then has bullet 1 in the following list to say that it also includes the processing.
[15:57:41] <linuxwolf> I still think it comes down to how one defines processing
[15:57:54] <ralphm> Let's put it differently: I am going to suggest this text gets changed.
[15:58:24] <ralphm> because a) servers don't work that way, b) I think it is undesirable
[15:58:50] <ralphm> c) it might even be harmful
[16:04:37] <ralphm> it seems MattJ and linuxwolf agree with me. I'm curious about other server devs of course. I also think my interpretation shouldn't impact clients at all.
[16:05:08] <Kev> Other than changing the defined behaviour of the server.
[16:06:09] <ralphm> Kev: do you clients send out an iq and ignore or error on any other stanza from the same (local?) entity until that iq gets a response?
[16:06:15] <ralphm> do you*r*
[16:07:18] <Kev> Ignore or error? No. I'm not convinced it won't change behaviour, though, if the client e.g. doesn't know its own nickname before it tries to join bookmarked rooms.
[16:07:41] <ralphm> Kev: and to be sure: we don't agree that it changes the behaviour. My take is that it clarifies it.
[16:10:12] <ralphm> Kev: in general, if you need the output of one request as the input for another, you require order on the client side. That doesn't impact this at all.
[16:10:39] <linuxwolf> Kev: now this is just silliness … of course you can't act on data you don't yet know about, but that doesn't mean you can't handle an iq:version returning before that vcard or PEP item retrieve
[16:11:27] <Kev> linuxwolf: Unless the PEP item retrieve is also part of determining your nickname for joining MUCs, for example.
[16:11:46] <Kev> Or if the PEP retrieve is for your bookmarks and you get those before you know your nickname.
[16:12:17] <linuxwolf> Kev: right … but how does the iq:version impact this? Does swift break if it got the iq:version response before it got the PEP item-retrieve, even though you (theoretically) sent them in reverse order?
[16:12:26] <ralphm> Kev: again, if you need all responses, then yes, you should wait for all of them
[16:12:26] <Kev> Of course, clients could be written (subject to significant additional latency) to deal with not having guaranteed order - but at the moment 6120 says that the server will process its requests in order, and as such they don't need to.
[16:12:50] <linuxwolf> there is no additional latency
[16:13:08] <Kev> linuxwolf: There is if you're suggesting that where ordering matters you must wait for a reply to the previous before requsting the next, which you suggested earlier.
[16:13:29] <ralphm> Kev: only if you need the reponse!
[16:13:33] <linuxwolf> Kev: for those things that matter, you'd have to no matter what!
[16:13:51] <linuxwolf> I think we're agreed you can't join rooms until you know what rooms to join, yes?
[16:14:09] <linuxwolf> and, you can't join room until you know what the user's preferred and/or registered nick is, yes?
[16:14:25] <linuxwolf> but, that doesn't mean the client must way for the bookmark request to complete ...
[16:14:39] <linuxwolf> … before requesting the PEP-registered nickname
[16:14:42] <ralphm> Kev: what linuxwolf and I are saying actually improves latency.
[16:15:04] <ralphm> and also wastes less server resources as a bonus
[16:15:06] <linuxwolf> nor does it mean you must wait for one particular MUC room to respond to your register get before you send the next
[16:15:48] *** Kooda shows as "online"
[16:15:52] <linuxwolf> for those things I MUST have the result, they get sent serially, pending said response
[16:16:19] <Kev> Except 6120 says you don't need to do that, because the server will enforce ordering.
[16:16:27] <Kev> Sure, you *can* do it, but you don't need it.
[16:16:42] <ralphm> assuming again that the MUC room is local, I'd say that communicating with two rooms is talking to different (bare) JIDs, so that doesn't apply.
[16:17:03] <ralphm> Kev: you keep repeating that the RFC says that, but it is your interpretation thereof
[16:17:12] <Kev> Sure, based on reading the words in it :p
[16:17:56] <Kev> The only way around it is if you start twisting 'processing' to mean 'doing some things it was asked to do, but not all of them'.
[16:18:07] <ralphm> Kev: accept that other people might interpret words differently. If you hate that, provide functional tests for the next revision.
[16:18:14] <linuxwolf> Kev: yes, a lot of have
[16:18:32] <linuxwolf> because when you're dealing with 100k's to 1M's of users, it tend to need to
[16:18:32] <Kev> And elsewhere there's text that says, in a different context, that processing includes sending the reply.
[16:19:06] <ralphm> I have to eat now
[16:19:13] <ralphm> to be continued
[16:19:27] <linuxwolf> I need to get back to my day job
[16:23:33] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[16:23:39] *** MattJ shows as "online"
[16:23:46] <Kev> OK, I found that 6121 says that IQ processing includes sending the reply stanza when the request is sent to the bare JID (8.5.2.1.2) - I imagine we can find similar text for the other cases.
[16:24:16] *** ralphm shows as "away" and his status message is "Away as a result of being idle"
[16:27:23] *** stpeter has joined the room
[16:34:15] *** ralphm shows as "xa" and his status message is "Not available as a result of being idle"
[16:51:14] *** ralphm shows as "online"
[16:51:46] <ralphm> it is too bad stpeter missed all of that
[16:52:28] <Tobias> there are logs
[16:52:43] <ralphm> oh, is that new?
[16:52:44] <stpeter> sure :)
[16:52:45] *ralphm ducks
[16:53:00] <stpeter> http://xmpp.org:5290/muc_log/muc.xmpp.org/council/120411/
[16:53:19] <stpeter> will read later, but right now I'm deep in work on SASL and PRECIS
[16:53:20] <ralphm> yeah, I found them. I thought they were disfunctional
[16:53:36] <Tobias> they are also mentioned in the subject :)
[16:53:41] <stpeter> ralphm: they were for a little while, yes
[16:53:53] <stpeter> right, http://logs.xmpp.org/council/ is easier to remember :)
[16:53:59] <ralphm> Tobias: that's how I found them. Obviously I knew we used to have them
[16:54:13] <Tobias> somehow swift disallows copying the URL out of there :/
[16:54:26] <Tobias> must be a security feature
[16:54:48] <ralphm> Tobias: maybe you tried to do it out-of-order
[16:55:02] *** linuxwolf has left the room
[16:55:10] <Tobias> heh
[16:55:37] <Kev> Yeah, I'm not sure why that doesn't work. Patches welcome.
[16:58:36] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[17:01:13] *** MattJ shows as "online"
[17:01:31] *** ralphm shows as "away" and his status message is "Away as a result of being idle"
[17:06:14] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[17:08:10] *** linuxwolf has joined the room
[17:10:13] *** MattJ shows as "online"
[17:11:31] *** ralphm shows as "xa" and his status message is "Not available as a result of being idle"
[17:11:50] *** Kooda shows as "away" and his status message is "mange"
[17:23:38] *** stpeter shows as "away" and his status message is "wandered off..."
[17:23:54] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[17:26:36] *** Kooda shows as "online"
[17:28:39] *** MattJ shows as "online"
[17:28:47] *** stpeter shows as "online"
[17:31:46] *** ralphm shows as "online"
[17:47:12] <ralphm> stpeter: by the way, the calendar entry for the council meeting was an hour late
[17:49:12] <stpeter> damn timezones
[17:49:27] <Kev> 1500UTC we're meeting at these days.
[17:49:29] <stpeter> it *seemed* wrong when I typed in 16:00
[17:49:39] <stpeter> but I just copied that over from previous meetings
[17:49:55] <ralphm> it was correct in our winter
[17:51:24] <stpeter> fixed for next week's meeting
[18:00:14] *** Kooda shows as "online"
[18:00:45] *** stpeter shows as "away" and his status message is "wandered off..."
[18:05:12] *** linuxwolf shows as "away" and his status message is "stuffage"
[18:06:02] *** stpeter shows as "online"
[18:06:25] *** stpeter shows as "xa" and his status message is "lunch"
[18:14:40] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[18:15:11] *** linuxwolf shows as "away" and his status message is "stuffage"
[18:15:34] *** MattJ shows as "online"
[18:18:29] <ralphm> stpeter: really? I don't see an event next week.
[18:29:03] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[18:33:50] *** Kev shows as "away"
[18:39:02] *** MattJ shows as "xa" and his status message is " (Not available as a result of being idle more than 15 min)"
[19:13:36] *** linuxwolf shows as "away" and his status message is "stuffage"
[19:13:39] *** linuxwolf shows as "online"
[19:13:45] *** stpeter shows as "online"
[19:26:26] <stpeter> ralphm: "refresh all calendars" worked in my calendaring program
[19:27:46] <linuxwolf> hrm … it's not showing up for me, either
[19:28:30] <linuxwolf> the XSF Calendar or the XMPP Council Calendar?
[19:29:48] <ralphm> guess google doesn't pull it often or something
[19:30:04] <ralphm> I'm using the latter
[19:33:03] <stpeter> clearly we need calendaring over pubsub :P
[19:33:25] <linuxwolf> if I use < http://xmpp.org/xsf/XSF.ics >, then I see it … but I was originally using < http://xmpp.org/xsf/xsf-all.ics >
[19:34:21] *** MattJ shows as "online"
[19:34:40] <stpeter> hmm
[19:34:52] <linuxwolf> the latter now emits a "fatal error"
[19:34:54] <stpeter> I always use the files at http://xmpp.org/calendar/
[19:35:21] <ralphm> why does everything move!
[19:35:27] <stpeter> heh
[19:35:32] <ralphm> and not leave any forwarding address
[19:35:37] *stpeter puts a redirect in place
[19:35:42] <ralphm> COOL URLS DON'T CHANGE!
[19:35:48] <ralphm> damnit
[19:35:59] <ralphm> /rant
[19:36:22] <linuxwolf> < http://maddox.xmission.com/ >
[19:37:14] <stpeter> actually lighttpd already had a redirect in place:

"^/xsf/XSF.ics" => "http://xmpp.org/calendar/xsf-all.ics"

[19:37:25] <linuxwolf> hrmph
[19:37:34] <linuxwolf> ah … calendar
[19:38:08] <stpeter> why do people use applications that can't follow http redirects!
[19:38:22] <stpeter> COOL APPS FOLLOW SPECS!
[19:38:34] <linuxwolf> I don't know if I can trust this calendar
[19:38:39] <linuxwolf> it's not using TLS d-:
[19:38:57] <stpeter> true
[19:39:04] <stpeter> TLS everywhere!
[19:39:06] <stpeter>
[19:39:09] <linuxwolf> ALL THE COOL THINGS USE TLS
[19:39:24] <linuxwolf> UTF-8 Everywhere™®
[19:39:30] <stpeter> :)
[19:39:39] <stpeter> :)™
[19:39:51] <linuxwolf> I now realize our lunch conversation is bleeding into this place
[19:39:58] <stpeter> yepper!
[19:40:12] <linuxwolf> I think I need another meeting
[19:40:27] <stpeter> I'm sure you'll have another one soon enough
[19:41:00] <linuxwolf> indubitably
[19:51:04] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[19:51:08] *** MattJ shows as "online"
[19:54:26] *** linuxwolf shows as "away" and his status message is "stuffage"
[19:55:45] *** linuxwolf has left the room
[19:58:40] *** linuxwolf has joined the room
[20:01:19] *** ralphm shows as "away" and his status message is "Away as a result of being idle"
[20:04:02] *** linuxwolf shows as "away" and his status message is "stuffage"
[20:04:06] *** linuxwolf shows as "online"
[20:06:53] *** ralphm shows as "online"
[20:14:43] *** stpeter shows as "away" and his status message is "wandered off..."
[20:23:29] *** linuxwolf shows as "away" and his status message is "stuffage"
[20:28:29] *** linuxwolf shows as "away" and his status message is "stuffage"
[20:34:06] *** Kev shows as "online"
[20:34:43] *** stpeter shows as "xa" and his status message is "wandered off..."
[20:56:43] *** stpeter shows as "online"
[21:07:36] *** stpeter shows as "away" and his status message is "wandered off..."
[21:17:08] *** linuxwolf shows as "away" and his status message is "stuffage"
[21:17:08] *** linuxwolf has left the room
[21:17:13] *** stpeter shows as "online"
[21:22:09] *** Kev shows as "away"
[21:28:04] *** stpeter shows as "away" and his status message is "wandered off..."
[21:30:38] *** linuxwolf has joined the room
[21:31:48] *** linuxwolf has left the room
[21:32:19] *** linuxwolf has joined the room
[21:32:52] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[21:34:51] *** MattJ shows as "online"
[21:38:03] *** stpeter shows as "online"
[21:42:14] *** linuxwolf shows as "away" and his status message is "stuffage"
[21:43:04] *** stpeter has left the room
[21:47:57] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[21:48:27] *** MattJ shows as "online"
[21:53:33] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[21:55:23] *** MattJ shows as "online"
[21:58:42] *** linuxwolf shows as "away" and his status message is "stuffage"
[21:58:42] *** linuxwolf has left the room
[22:13:37] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[22:16:15] *** MattJ shows as "online"
[22:21:31] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[22:22:33] *** MattJ shows as "online"
[22:36:25] *** MattJ shows as "away" and his status message is " (Away as a result of being idle more than 5 min)"
[22:42:53] *** MattJ shows as "online"
[23:15:04] *** Tobias has left the room
[23:19:08] *** MattJ has left the room