XMPP Council - 2012-04-11

  1. Kev has left
  2. Kev has joined
  3. MattJ has left
  4. Tobias has joined
  5. Tobias has left
  6. Tobias has joined
  7. linuxwolf has joined
  8. Tobias has left
  9. Kev Meeting with nothing on the agenda in ~55 minutes.
  10. linuxwolf w00t
  11. MattJ has joined
  12. MattJ It took me a long time to work out "Today being Monday, tomorrow being Wednesday"
  13. ralphm has joined
  14. Kev MattJ: Submitted MAM yet?
  15. MattJ Not yet
  16. ralphm MattJ: +1 on stream:error everywhere
  17. MattJ Thanks, good to know I'm not just missing the point of that thread
  18. MattJ You MUST answer <iq> requests, but does that mean we shouldn't send a stream:error if there are any outstanding?
  19. Kev Oh, good question. Yes, I guess it does :)
  20. 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
  21. linuxwolf or you treat the stream:error as a "catastrophic failure", like a severed network … d-:
  22. 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.
  23. linuxwolf /nod … it's what I've done just about everywhere, too
  24. ralphm mostly because you can't know what really happens
  25. linuxwolf if a server's at the point of emitting a stream:error, you have bigger problems than unanswered iq's
  26. Kev I think the order here is actually mandated.
  27. 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.
  28. Kev Stream errors for server going down or whatever don't fit into this, I realise.
  29. linuxwolf right
  30. ralphm also http://xmpp.org/rfcs/rfc6121.html#roster-syntax-actions-push
  31. linuxwolf I rarely see the <illegal/>, but definitely see the crash (-:
  32. Tobias has joined
  33. ralphm … which, in spite of the MUST, still allows for not sending a response
  34. linuxwolf graceful-crash?
  35. MattJ Kev, define "finished" (with the iq)
  36. linuxwolf (-:
  37. MattJ Kev, does handling in order require responding in order?
  38. Kev Of course.
  39. ralphm Of course roster pushes in any new design would be <message/> stanzas
  40. Kev It's not handled until the server has replied.
  41. MattJ Ok, so...
  42. linuxwolf ralphm: everything is pubsub
  43. ralphm linuxwolf: hah, earlier specs for pubsub used IQs for notifications
  44. 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?
  45. ralphm linuxwolf: this is one reason I think that's a bad idea
  46. linuxwolf in any new design, we can just do <publish/>, <subscribe/>, and <notify/> as TLS (top-level-stanzas)
  47. linuxwolf "just"
  48. ralphm linuxwolf: I guess we'd just drop '<presence/>' and keep '<message/>' and '<iq/>'.
  49. linuxwolf yeah, pretty much (-:
  50. Kev MattJ: It's not the server that's processing the iq.
  51. MattJ So we can have a stream:error before the iq is responded to?
  52. Kev Yes.
  53. MattJ Good
  54. ralphm Of course
  55. Kev Just not before an iq is responded to by the server.
  56. Kev A roster get or whatever.
  57. linuxwolf s/an iq is/an iq addressed to the server is/ ?
  58. Kev Right.
  59. MattJ I think you're talking about something aside from the main issue
  60. Kev Naturally.
  61. stpeter has joined
  62. 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
  63. 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
  64. ralphm Kev: are you also saying that responses to iqs to the same entity should come back in order?
  65. stpeter gosh, its seems that I've missed a fun discussion
  66. MattJ and I'm thirdly not convinced (but admittedly on more shaky ground) that iqs must be responded to in order
  67. MattJ because I don't equate "handling" with "responding"
  68. linuxwolf MattJ: I agree
  69. ralphm MattJ: agreed, that seems QUITE problematic, to me.
  70. MattJ stpeter, pre-council meeting :P
  71. linuxwolf especially if dealing with large scale
  72. stpeter grumbles about a conference call that someone expected him to be on right now
  73. 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.
  74. ralphm stpeter: claim atmospheric issues
  75. MattJ or claim it's Tuesday
  76. stpeter damn proprietary Outlook invites
  77. linuxwolf hah
  78. linuxwolf fumso
  79. linuxwolf (f*** u microsoft office!)
  80. Kev Righty.
  81. Kev Shall we have our not-a-meeting, then?
  82. Kev 1) Roll call.
  83. Kev I'm here.
  84. linuxwolf presente
  85. stpeter is still on his conference call
  86. MattJ Gift
  87. ralphm hi
  88. Kev Tobias: ?
  89. Tobias kev
  90. Tobias ah..council meeting
  91. Tobias youp..i'm here
  92. Kev Did anyone have anything for the agenda?
  93. stpeter ok my call is done
  94. Kev I'll add GSoC, then
  95. Kev 2) GSoC
  96. Kev The applications are in, thanks to the people who answered my call for mentors and have commented on proposals.
  97. Kev I submitted the slot requests to Google yesterday, based on the applications people volunteered to mentor and the comments on the proposals.
  98. 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).
  99. Tobias ok
  100. Kev That's about it.
  101. linuxwolf nice
  102. 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.
  103. linuxwolf (-:
  104. 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?
  105. 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.
  106. Kev google-melange.com
  107. stpeter ah ok
  108. stpeter thanks
  109. Kev I think that's everything GSoCcish.
  110. Kev 3) Date of next meeting.
  111. Kev SBTSBC
  112. Kev ?
  113. linuxwolf wfm
  114. linuxwolf hopefully MAM will be a topic of discussion
  115. linuxwolf /zing
  116. Kev We can but hope. Nearly 50% of the XSF's GSoC applications were to work on MAM support.
  117. stpeter heh
  118. Kev Right, SBTSBC it is.
  119. Kev 4) AOB?
  120. ralphm nope
  121. linuxwolf nada
  122. MattJ None
  123. Tobias nope
  124. Kev Sounds good then.
  125. 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
  126. Kev Thanks all.
  127. Kev bangs the gavel.
  128. ralphm Kev: I'm still interested in your responses to the pre-meeting discussion
  129. Kev ralphm: Interested in what way?
  130. stpeter closes his computer and heads to the light rail station
  131. ralphm Kev: well, for example, the question I asked
  132. Kev That's not entirely unambigous at this point :p
  133. Kev stpeter: Enjoy.
  134. stpeter has left
  135. linuxwolf goes for caffeine
  136. ralphm ralphm: Kev: are you also saying that responses to iqs to the same entity should come back in order?
  137. ralphm (and the stuff following that)
  138. Kev Yes.
  139. 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.
  140. ralphm Kev: I'll rephrase
  141. ralphm Kev: are you saying that responses to iqs should come back in the same order as the requests?
  142. Kev To a given bare JID? Yes.
  143. ralphm As I said before, that seems problematic.
  144. Kev I don't see why.
  145. Kev It's what 6120 says you need to do.
  146. 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.
  147. Kev The second iq must be pipelined until the first is processed.
  148. ralphm I'm not sure if I agree this is what RFC 6120 says, but I do think it is stupid
  149. ralphm and I don't see why you'd want that kind of behaviour
  150. Kev Interesting, I'm wrong, I think.
  151. Kev What I say only holds true if the entity is a server.
  152. ralphm Really? Also, define 'server'
  153. Kev If it's a client, there seems to be no restriction on the processing order of data it receives.
  154. Kev "Thing at the S end of a C2S link, or at the end of an S2S link"
  155. ralphm also, 'processing' is rather vague
  156. ralphm you also mentioned MUC as an example
  157. Kev Did I?
  158. ralphm Oh, no MattJ did
  159. ralphm He mentioned waiting for the response to an vcard request
  160. 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?
  161. ralphm (for the requesting occupant)
  162. Kev That's a fun question.
  163. ralphm RFC 6120 says:
  164. 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.
  165. ralphm I believe that the 'if' is rather (intentionally) vague, and not as strict as you seem to make it out to be.
  166. Kev Right.
  167. ralphm e.g. I'd say it does apply for subsequent publish requests to the same node
  168. Kev It seems that the following cases are strictly linear:
  169. ralphm but not to different nodes, or any other unrelated iq or message
  170. Kev Sending anything to your bare JID Routing stanzas Receiving routed stanzas
  171. Kev And that for other requests it's vague.
  172. Kev Oh, no, I'm wrong.
  173. Kev To your bare JID or to the server itself.
  174. ralphm so that's all about delivery
  175. ralphm and I agree with *that*
  176. 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.
  177. 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
  178. Kev That much is entirely clear in 6120
  179. Kev It must process those requests in order.
  180. MattJ Process, or respond?
  181. ralphm what MattJ says
  182. ralphm this is crucial
  183. ralphm and not clear at all to me
  184. Kev They're one and the same.
  185. MattJ and if this is ambiguous, I think it should be made clear that handle/process != respond
  186. ralphm Kev: I strongly disagree
  187. ralphm Kev: and I don't see any text to support that
  188. 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.
  189. ralphm Sure I can!
  190. ralphm If I set my mind to it.
  191. ralphm Kev: also, I am not sure that RFC 6120, section 10.1, shares your interpretation of 'processing' in this case.
  192. ralphm It does not talk about processing requests, but rather processing of stanzas.
  193. Kev "e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM]"
  194. Kev I'd say that was pretty unambiguous.
  195. ralphm I think that's because of the paragraph I pasted. So a business rule for this particular exchange of different related stanzas.
  196. ralphm So I agree on that example, but not on the general case.
  197. 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])."
  198. ralphm there is no reason to delay responding to an iq:version request if you sent out a roster request before that
  199. Kev It is clear that's just an example of the general case to which this rule applies.
  200. 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.
  201. Kev I think this is a good rule.
  202. ralphm I think it is a nightmare.
  203. 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.
  204. 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 :)
  205. ralphm Kev: seriously?
  206. 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?
  207. Kev No, not really, because just about all queries a client sends to a server it's going to get responses to ~instantly anyway.
  208. 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.
  209. Kev And for heavy processing platforms (i.e. not the clients own server), these rules don't apply.
  210. 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.
  211. linuxwolf Kev: disco
  212. Kev linuxwolf: Disco should return instantly too.
  213. Kev Unless you were just adding it to the list, rather than a counterpoint, in which case...right.
  214. linuxwolf this "instantly" is a big assumption, IMO
  215. linuxwolf and I was adding to the list
  216. Kev disco#items to a MUC service, on the other hand, isn't subject to these rules.
  217. ralphm Kev: I'm willing to bet that most server developers strongly disagree with your stance on this.
  218. linuxwolf they do
  219. 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.
  220. Kev ralphm: It could, this is true.
  221. 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
  222. linuxwolf and that is something we ought to recommend somewhere anyway
  223. Kev linuxwolf: Well, no, you don't need to, because 6120 says it'll do it for you.
  224. linuxwolf Kev: as this discussion points out, your stance is not universally accepted
  225. ralphm linuxwolf: so that's really a business rule of particular exchanges, not of all message/iq processing, right?
  226. linuxwolf processing is a vague term
  227. linuxwolf ralphm: true, but at least for my experiences, it's true far more often than it's false
  228. ralphm linuxwolf: but individually, per types of exchanges (say presence/roster v.s. iq version v.s. pubsub publish)
  229. ralphm linuxwolf: not on all incoming messages/iqs
  230. linuxwolf ralphm: true
  231. Kev linuxwolf: It's not vague, at least for iqs it's fairly clearly defined.
  232. Kev And it includes sending the response.
  233. ralphm Kev: if people disagree with an interpretation (in general) it is not clearly defined
  234. linuxwolf ralphm: it comes down to what's important to "ensure" is handled
  235. Kev I don't see how you can possibly interprep 6120 to not think iq processing includes sending the result.
  236. ralphm Kev: see above.
  237. Kev ralphm: Which part of the text makes you think it doesn't include the return?
  238. Kev "in general the server will respond to the IQ stanza"
  239. 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
  240. linuxwolf which therefore means it doesn't necessarily have to respond in the received order
  241. 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"
  242. ralphm Kev: which for my example is false.
  243. Kev ralphm: Yes, that is for stanzas that don't fall under the previous list.
  244. ralphm Kev: not in my world
  245. 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"
  246. Kev That really doesn't seem ambiguous.
  247. ralphm as long as you talk about stanzas, it is about delivery
  248. ralphm in my opinion
  249. 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.
  250. linuxwolf I still think it comes down to how one defines processing
  251. ralphm Let's put it differently: I am going to suggest this text gets changed.
  252. ralphm because a) servers don't work that way, b) I think it is undesirable
  253. ralphm c) it might even be harmful
  254. 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.
  255. Kev Other than changing the defined behaviour of the server.
  256. 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?
  257. ralphm do you*r*
  258. 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.
  259. ralphm Kev: and to be sure: we don't agree that it changes the behaviour. My take is that it clarifies it.
  260. 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.
  261. 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
  262. Kev linuxwolf: Unless the PEP item retrieve is also part of determining your nickname for joining MUCs, for example.
  263. Kev Or if the PEP retrieve is for your bookmarks and you get those before you know your nickname.
  264. 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?
  265. ralphm Kev: again, if you need all responses, then yes, you should wait for all of them
  266. 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.
  267. linuxwolf there is no additional latency
  268. 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.
  269. ralphm Kev: only if you need the reponse!
  270. linuxwolf Kev: for those things that matter, you'd have to no matter what!
  271. linuxwolf I think we're agreed you can't join rooms until you know what rooms to join, yes?
  272. linuxwolf and, you can't join room until you know what the user's preferred and/or registered nick is, yes?
  273. linuxwolf but, that doesn't mean the client must way for the bookmark request to complete ...
  274. linuxwolf … before requesting the PEP-registered nickname
  275. ralphm Kev: what linuxwolf and I are saying actually improves latency.
  276. ralphm and also wastes less server resources as a bonus
  277. linuxwolf nor does it mean you must wait for one particular MUC room to respond to your register get before you send the next
  278. linuxwolf for those things I MUST have the result, they get sent serially, pending said response
  279. Kev Except 6120 says you don't need to do that, because the server will enforce ordering.
  280. Kev Sure, you *can* do it, but you don't need it.
  281. 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.
  282. ralphm Kev: you keep repeating that the RFC says that, but it is your interpretation thereof
  283. Kev Sure, based on reading the words in it :p
  284. 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'.
  285. ralphm Kev: accept that other people might interpret words differently. If you hate that, provide functional tests for the next revision.
  286. linuxwolf Kev: yes, a lot of have
  287. linuxwolf because when you're dealing with 100k's to 1M's of users, it tend to need to
  288. Kev And elsewhere there's text that says, in a different context, that processing includes sending the reply.
  289. ralphm I have to eat now
  290. ralphm to be continued
  291. linuxwolf I need to get back to my day job
  292. Kev OK, I found that 6121 says that IQ processing includes sending the reply stanza when the request is sent to the bare JID ( - I imagine we can find similar text for the other cases.
  293. stpeter has joined
  294. ralphm it is too bad stpeter missed all of that
  295. Tobias there are logs
  296. ralphm oh, is that new?
  297. stpeter sure :)
  298. ralphm ducks
  299. stpeter http://xmpp.org:5290/muc_log/muc.xmpp.org/council/120411/
  300. stpeter will read later, but right now I'm deep in work on SASL and PRECIS
  301. ralphm yeah, I found them. I thought they were disfunctional
  302. Tobias they are also mentioned in the subject :)
  303. stpeter ralphm: they were for a little while, yes
  304. stpeter right, http://logs.xmpp.org/council/ is easier to remember :)
  305. ralphm Tobias: that's how I found them. Obviously I knew we used to have them
  306. Tobias somehow swift disallows copying the URL out of there :/
  307. Tobias must be a security feature
  308. ralphm Tobias: maybe you tried to do it out-of-order
  309. linuxwolf has left
  310. Tobias heh
  311. Kev Yeah, I'm not sure why that doesn't work. Patches welcome.
  312. linuxwolf has joined
  313. ralphm stpeter: by the way, the calendar entry for the council meeting was an hour late
  314. stpeter damn timezones
  315. Kev 1500UTC we're meeting at these days.
  316. stpeter it *seemed* wrong when I typed in 16:00
  317. stpeter but I just copied that over from previous meetings
  318. ralphm it was correct in our winter
  319. stpeter fixed for next week's meeting
  320. ralphm stpeter: really? I don't see an event next week.
  321. stpeter ralphm: "refresh all calendars" worked in my calendaring program
  322. linuxwolf hrm … it's not showing up for me, either
  323. linuxwolf the XSF Calendar or the XMPP Council Calendar?
  324. ralphm guess google doesn't pull it often or something
  325. ralphm I'm using the latter
  326. stpeter clearly we need calendaring over pubsub :P
  327. 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 >
  328. stpeter hmm
  329. linuxwolf the latter now emits a "fatal error"
  330. stpeter I always use the files at http://xmpp.org/calendar/
  331. ralphm why does everything move!
  332. stpeter heh
  333. ralphm and not leave any forwarding address
  334. stpeter puts a redirect in place
  335. ralphm COOL URLS DON'T CHANGE!
  336. ralphm damnit
  337. ralphm /rant
  338. linuxwolf < http://maddox.xmission.com/ >
  339. stpeter actually lighttpd already had a redirect in place: "^/xsf/XSF.ics" => "http://xmpp.org/calendar/xsf-all.ics"
  340. linuxwolf hrmph
  341. linuxwolf ah … calendar
  342. stpeter why do people use applications that can't follow http redirects!
  343. stpeter COOL APPS FOLLOW SPECS!
  344. linuxwolf I don't know if I can trust this calendar
  345. linuxwolf it's not using TLS d-:
  346. stpeter true
  347. stpeter TLS everywhere!
  348. stpeter
  349. linuxwolf ALL THE COOL THINGS USE TLS
  350. linuxwolf UTF-8 Everywhere™®
  351. stpeter :)
  352. stpeter :)™
  353. linuxwolf I now realize our lunch conversation is bleeding into this place
  354. stpeter yepper!
  355. linuxwolf I think I need another meeting
  356. stpeter I'm sure you'll have another one soon enough
  357. linuxwolf indubitably
  358. linuxwolf has left
  359. linuxwolf has joined
  360. linuxwolf has left
  361. linuxwolf has joined
  362. linuxwolf has left
  363. linuxwolf has joined
  364. stpeter has left
  365. linuxwolf has left
  366. Tobias has left
  367. MattJ has left