XMPP Council - 2012-04-11

  1. Kev

    Meeting with nothing on the agenda in ~55 minutes.

  2. linuxwolf


  3. MattJ

    It took me a long time to work out "Today being Monday, tomorrow being Wednesday"

  4. Kev

    MattJ: Submitted MAM yet?

  5. MattJ

    Not yet

  6. ralphm

    MattJ: +1 on stream:error everywhere

  7. MattJ

    Thanks, good to know I'm not just missing the point of that thread

  8. MattJ

    You MUST answer <iq> requests, but does that mean we shouldn't send a stream:error if there are any outstanding?

  9. Kev

    Oh, good question. Yes, I guess it does :)

  10. 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

  11. linuxwolf

    or you treat the stream:error as a "catastrophic failure", like a severed network … d-:

  12. 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.

  13. linuxwolf

    /nod … it's what I've done just about everywhere, too

  14. ralphm

    mostly because you can't know what really happens

  15. linuxwolf

    if a server's at the point of emitting a stream:error, you have bigger problems than unanswered iq's

  16. Kev

    I think the order here is actually mandated.

  17. 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.

  18. Kev

    Stream errors for server going down or whatever don't fit into this, I realise.

  19. linuxwolf


  20. ralphm

    also http://xmpp.org/rfcs/rfc6121.html#roster-syntax-actions-push

  21. linuxwolf

    I rarely see the <illegal/>, but definitely see the crash (-:

  22. ralphm

    … which, in spite of the MUST, still allows for not sending a response

  23. linuxwolf


  24. MattJ

    Kev, define "finished" (with the iq)

  25. linuxwolf


  26. MattJ

    Kev, does handling in order require responding in order?

  27. Kev

    Of course.

  28. ralphm

    Of course roster pushes in any new design would be <message/> stanzas

  29. Kev

    It's not handled until the server has replied.

  30. MattJ

    Ok, so...

  31. linuxwolf

    ralphm: everything is pubsub

  32. ralphm

    linuxwolf: hah, earlier specs for pubsub used IQs for notifications

  33. 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?

  34. ralphm

    linuxwolf: this is one reason I think that's a bad idea

  35. linuxwolf

    in any new design, we can just do <publish/>, <subscribe/>, and <notify/> as TLS (top-level-stanzas)

  36. linuxwolf


  37. ralphm

    linuxwolf: I guess we'd just drop '<presence/>' and keep '<message/>' and '<iq/>'.

  38. linuxwolf

    yeah, pretty much (-:

  39. Kev

    MattJ: It's not the server that's processing the iq.

  40. MattJ

    So we can have a stream:error before the iq is responded to?

  41. Kev


  42. MattJ


  43. ralphm

    Of course

  44. Kev

    Just not before an iq is responded to by the server.

  45. Kev

    A roster get or whatever.

  46. linuxwolf

    s/an iq is/an iq addressed to the server is/ ?

  47. Kev


  48. MattJ

    I think you're talking about something aside from the main issue

  49. Kev


  50. 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

  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

  52. ralphm

    Kev: are you also saying that responses to iqs to the same entity should come back in order?

  53. stpeter

    gosh, its seems that I've missed a fun discussion

  54. MattJ

    and I'm thirdly not convinced (but admittedly on more shaky ground) that iqs must be responded to in order

  55. MattJ

    because I don't equate "handling" with "responding"

  56. linuxwolf

    MattJ: I agree

  57. ralphm

    MattJ: agreed, that seems QUITE problematic, to me.

  58. MattJ

    stpeter, pre-council meeting :P

  59. linuxwolf

    especially if dealing with large scale

  60. stpeter grumbles about a conference call that someone expected him to be on right now

  61. 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.

  62. ralphm

    stpeter: claim atmospheric issues

  63. MattJ

    or claim it's Tuesday

  64. stpeter

    damn proprietary Outlook invites

  65. linuxwolf


  66. linuxwolf


  67. linuxwolf

    (f*** u microsoft office!)

  68. Kev


  69. Kev

    Shall we have our not-a-meeting, then?

  70. Kev

    1) Roll call.

  71. Kev

    I'm here.

  72. linuxwolf


  73. stpeter is still on his conference call

  74. MattJ


  75. ralphm


  76. Kev

    Tobias: ?

  77. Tobias


  78. Tobias

    ah..council meeting

  79. Tobias

    youp..i'm here

  80. Kev

    Did anyone have anything for the agenda?

  81. stpeter

    ok my call is done

  82. Kev

    I'll add GSoC, then

  83. Kev

    2) GSoC

  84. Kev

    The applications are in, thanks to the people who answered my call for mentors and have commented on proposals.

  85. Kev

    I submitted the slot requests to Google yesterday, based on the applications people volunteered to mentor and the comments on the proposals.

  86. 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).

  87. Tobias


  88. Kev

    That's about it.

  89. linuxwolf


  90. 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.

  91. linuxwolf


  92. 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?

  93. 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.

  94. Kev


  95. stpeter

    ah ok

  96. stpeter


  97. Kev

    I think that's everything GSoCcish.

  98. Kev

    3) Date of next meeting.

  99. Kev


  100. Kev


  101. linuxwolf


  102. linuxwolf

    hopefully MAM will be a topic of discussion

  103. linuxwolf


  104. Kev

    We can but hope. Nearly 50% of the XSF's GSoC applications were to work on MAM support.

  105. stpeter


  106. Kev

    Right, SBTSBC it is.

  107. Kev

    4) AOB?

  108. ralphm


  109. linuxwolf


  110. MattJ


  111. Tobias


  112. Kev

    Sounds good then.

  113. 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

  114. Kev

    Thanks all.

  115. Kev bangs the gavel.

  116. ralphm

    Kev: I'm still interested in your responses to the pre-meeting discussion

  117. Kev

    ralphm: Interested in what way?

  118. stpeter closes his computer and heads to the light rail station

  119. ralphm

    Kev: well, for example, the question I asked

  120. Kev

    That's not entirely unambigous at this point :p

  121. Kev

    stpeter: Enjoy.

  122. linuxwolf goes for caffeine

  123. ralphm

    ralphm: Kev: are you also saying that responses to iqs to the same entity should come back in order?

  124. ralphm

    (and the stuff following that)

  125. Kev


  126. 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.

  127. ralphm

    Kev: I'll rephrase

  128. ralphm

    Kev: are you saying that responses to iqs should come back in the same order as the requests?

  129. Kev

    To a given bare JID? Yes.

  130. ralphm

    As I said before, that seems problematic.

  131. Kev

    I don't see why.

  132. Kev

    It's what 6120 says you need to do.

  133. 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.

  134. Kev

    The second iq must be pipelined until the first is processed.

  135. ralphm

    I'm not sure if I agree this is what RFC 6120 says, but I do think it is stupid

  136. ralphm

    and I don't see why you'd want that kind of behaviour

  137. Kev

    Interesting, I'm wrong, I think.

  138. Kev

    What I say only holds true if the entity is a server.

  139. ralphm

    Really? Also, define 'server'

  140. Kev

    If it's a client, there seems to be no restriction on the processing order of data it receives.

  141. Kev

    "Thing at the S end of a C2S link, or at the end of an S2S link"

  142. ralphm

    also, 'processing' is rather vague

  143. ralphm

    you also mentioned MUC as an example

  144. Kev

    Did I?

  145. ralphm

    Oh, no MattJ did

  146. ralphm

    He mentioned waiting for the response to an vcard request

  147. 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?

  148. ralphm

    (for the requesting occupant)

  149. Kev

    That's a fun question.

  150. ralphm

    RFC 6120 says:

  151. 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.

  152. ralphm

    I believe that the 'if' is rather (intentionally) vague, and not as strict as you seem to make it out to be.

  153. Kev


  154. ralphm

    e.g. I'd say it does apply for subsequent publish requests to the same node

  155. Kev

    It seems that the following cases are strictly linear:

  156. ralphm

    but not to different nodes, or any other unrelated iq or message

  157. Kev

    Sending anything to your bare JID Routing stanzas Receiving routed stanzas

  158. Kev

    And that for other requests it's vague.

  159. Kev

    Oh, no, I'm wrong.

  160. Kev

    To your bare JID or to the server itself.

  161. ralphm

    so that's all about delivery

  162. ralphm

    and I agree with *that*

  163. 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.

  164. 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

  165. Kev

    That much is entirely clear in 6120

  166. Kev

    It must process those requests in order.

  167. MattJ

    Process, or respond?

  168. ralphm

    what MattJ says

  169. ralphm

    this is crucial

  170. ralphm

    and not clear at all to me

  171. Kev

    They're one and the same.

  172. MattJ

    and if this is ambiguous, I think it should be made clear that handle/process != respond

  173. ralphm

    Kev: I strongly disagree

  174. ralphm

    Kev: and I don't see any text to support that

  175. 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.

  176. ralphm

    Sure I can!

  177. ralphm

    If I set my mind to it.

  178. ralphm

    Kev: also, I am not sure that RFC 6120, section 10.1, shares your interpretation of 'processing' in this case.

  179. ralphm

    It does not talk about processing requests, but rather processing of stanzas.

  180. Kev

    "e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM]"

  181. Kev

    I'd say that was pretty unambiguous.

  182. ralphm

    I think that's because of the paragraph I pasted. So a business rule for this particular exchange of different related stanzas.

  183. ralphm

    So I agree on that example, but not on the general case.

  184. 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])."

  185. ralphm

    there is no reason to delay responding to an iq:version request if you sent out a roster request before that

  186. Kev

    It is clear that's just an example of the general case to which this rule applies.

  187. 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.

  188. Kev

    I think this is a good rule.

  189. ralphm

    I think it is a nightmare.

  190. 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.

  191. 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 :)

  192. ralphm

    Kev: seriously?

  193. 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?

  194. Kev

    No, not really, because just about all queries a client sends to a server it's going to get responses to ~instantly anyway.

  195. 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.

  196. Kev

    And for heavy processing platforms (i.e. not the clients own server), these rules don't apply.

  197. 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.

  198. linuxwolf

    Kev: disco

  199. Kev

    linuxwolf: Disco should return instantly too.

  200. Kev

    Unless you were just adding it to the list, rather than a counterpoint, in which case...right.

  201. linuxwolf

    this "instantly" is a big assumption, IMO

  202. linuxwolf

    and I was adding to the list

  203. Kev

    disco#items to a MUC service, on the other hand, isn't subject to these rules.

  204. ralphm

    Kev: I'm willing to bet that most server developers strongly disagree with your stance on this.

  205. linuxwolf

    they do

  206. 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.

  207. Kev

    ralphm: It could, this is true.

  208. 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

  209. linuxwolf

    and that is something we ought to recommend somewhere anyway

  210. Kev

    linuxwolf: Well, no, you don't need to, because 6120 says it'll do it for you.

  211. linuxwolf

    Kev: as this discussion points out, your stance is not universally accepted

  212. ralphm

    linuxwolf: so that's really a business rule of particular exchanges, not of all message/iq processing, right?

  213. linuxwolf

    processing is a vague term

  214. linuxwolf

    ralphm: true, but at least for my experiences, it's true far more often than it's false

  215. ralphm

    linuxwolf: but individually, per types of exchanges (say presence/roster v.s. iq version v.s. pubsub publish)

  216. ralphm

    linuxwolf: not on all incoming messages/iqs

  217. linuxwolf

    ralphm: true

  218. Kev

    linuxwolf: It's not vague, at least for iqs it's fairly clearly defined.

  219. Kev

    And it includes sending the response.

  220. ralphm

    Kev: if people disagree with an interpretation (in general) it is not clearly defined

  221. linuxwolf

    ralphm: it comes down to what's important to "ensure" is handled

  222. Kev

    I don't see how you can possibly interprep 6120 to not think iq processing includes sending the result.

  223. ralphm

    Kev: see above.

  224. Kev

    ralphm: Which part of the text makes you think it doesn't include the return?

  225. Kev

    "in general the server will respond to the IQ stanza"

  226. 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

  227. linuxwolf

    which therefore means it doesn't necessarily have to respond in the received order

  228. 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"

  229. ralphm

    Kev: which for my example is false.

  230. Kev

    ralphm: Yes, that is for stanzas that don't fall under the previous list.

  231. ralphm

    Kev: not in my world

  232. 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"

  233. Kev

    That really doesn't seem ambiguous.

  234. ralphm

    as long as you talk about stanzas, it is about delivery

  235. ralphm

    in my opinion

  236. 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.

  237. linuxwolf

    I still think it comes down to how one defines processing

  238. ralphm

    Let's put it differently: I am going to suggest this text gets changed.

  239. ralphm

    because a) servers don't work that way, b) I think it is undesirable

  240. ralphm

    c) it might even be harmful

  241. 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.

  242. Kev

    Other than changing the defined behaviour of the server.

  243. 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?

  244. ralphm

    do you*r*

  245. 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.

  246. ralphm

    Kev: and to be sure: we don't agree that it changes the behaviour. My take is that it clarifies it.

  247. 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.

  248. 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

  249. Kev

    linuxwolf: Unless the PEP item retrieve is also part of determining your nickname for joining MUCs, for example.

  250. Kev

    Or if the PEP retrieve is for your bookmarks and you get those before you know your nickname.

  251. 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?

  252. ralphm

    Kev: again, if you need all responses, then yes, you should wait for all of them

  253. 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.

  254. linuxwolf

    there is no additional latency

  255. 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.

  256. ralphm

    Kev: only if you need the reponse!

  257. linuxwolf

    Kev: for those things that matter, you'd have to no matter what!

  258. linuxwolf

    I think we're agreed you can't join rooms until you know what rooms to join, yes?

  259. linuxwolf

    and, you can't join room until you know what the user's preferred and/or registered nick is, yes?

  260. linuxwolf

    but, that doesn't mean the client must way for the bookmark request to complete ...

  261. linuxwolf

    … before requesting the PEP-registered nickname

  262. ralphm

    Kev: what linuxwolf and I are saying actually improves latency.

  263. ralphm

    and also wastes less server resources as a bonus

  264. linuxwolf

    nor does it mean you must wait for one particular MUC room to respond to your register get before you send the next

  265. linuxwolf

    for those things I MUST have the result, they get sent serially, pending said response

  266. Kev

    Except 6120 says you don't need to do that, because the server will enforce ordering.

  267. Kev

    Sure, you *can* do it, but you don't need it.

  268. 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.

  269. ralphm

    Kev: you keep repeating that the RFC says that, but it is your interpretation thereof

  270. Kev

    Sure, based on reading the words in it :p

  271. 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'.

  272. ralphm

    Kev: accept that other people might interpret words differently. If you hate that, provide functional tests for the next revision.

  273. linuxwolf

    Kev: yes, a lot of have

  274. linuxwolf

    because when you're dealing with 100k's to 1M's of users, it tend to need to

  275. Kev

    And elsewhere there's text that says, in a different context, that processing includes sending the reply.

  276. ralphm

    I have to eat now

  277. ralphm

    to be continued

  278. linuxwolf

    I need to get back to my day job

  279. 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.

  280. ralphm

    it is too bad stpeter missed all of that

  281. Tobias

    there are logs

  282. ralphm

    oh, is that new?

  283. stpeter

    sure :)

  284. ralphm ducks

  285. stpeter


  286. stpeter

    will read later, but right now I'm deep in work on SASL and PRECIS

  287. ralphm

    yeah, I found them. I thought they were disfunctional

  288. Tobias

    they are also mentioned in the subject :)

  289. stpeter

    ralphm: they were for a little while, yes

  290. stpeter

    right, http://logs.xmpp.org/council/ is easier to remember :)

  291. ralphm

    Tobias: that's how I found them. Obviously I knew we used to have them

  292. Tobias

    somehow swift disallows copying the URL out of there :/

  293. Tobias

    must be a security feature

  294. ralphm

    Tobias: maybe you tried to do it out-of-order

  295. Tobias


  296. Kev

    Yeah, I'm not sure why that doesn't work. Patches welcome.

  297. ralphm

    stpeter: by the way, the calendar entry for the council meeting was an hour late

  298. stpeter

    damn timezones

  299. Kev

    1500UTC we're meeting at these days.

  300. stpeter

    it *seemed* wrong when I typed in 16:00

  301. stpeter

    but I just copied that over from previous meetings

  302. ralphm

    it was correct in our winter

  303. stpeter

    fixed for next week's meeting

  304. ralphm

    stpeter: really? I don't see an event next week.

  305. stpeter

    ralphm: "refresh all calendars" worked in my calendaring program

  306. linuxwolf

    hrm … it's not showing up for me, either

  307. linuxwolf

    the XSF Calendar or the XMPP Council Calendar?

  308. ralphm

    guess google doesn't pull it often or something

  309. ralphm

    I'm using the latter

  310. stpeter

    clearly we need calendaring over pubsub :P

  311. 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 >

  312. stpeter


  313. linuxwolf

    the latter now emits a "fatal error"

  314. stpeter

    I always use the files at http://xmpp.org/calendar/

  315. ralphm

    why does everything move!

  316. stpeter


  317. ralphm

    and not leave any forwarding address

  318. stpeter puts a redirect in place

  319. ralphm


  320. ralphm


  321. ralphm


  322. linuxwolf

    < http://maddox.xmission.com/ >

  323. stpeter

    actually lighttpd already had a redirect in place: "^/xsf/XSF.ics" => "http://xmpp.org/calendar/xsf-all.ics"

  324. linuxwolf


  325. linuxwolf

    ah … calendar

  326. stpeter

    why do people use applications that can't follow http redirects!

  327. stpeter


  328. linuxwolf

    I don't know if I can trust this calendar

  329. linuxwolf

    it's not using TLS d-:

  330. stpeter


  331. stpeter

    TLS everywhere!

  332. stpeter

  333. linuxwolf


  334. linuxwolf

    UTF-8 Everywhere™®

  335. stpeter


  336. stpeter


  337. linuxwolf

    I now realize our lunch conversation is bleeding into this place

  338. stpeter


  339. linuxwolf

    I think I need another meeting

  340. stpeter

    I'm sure you'll have another one soon enough

  341. linuxwolf