XMPP Council - 2012-08-22

  1. Tobias has left

  2. m&m has left

  3. Немо has joined

  4. Немо has left

  5. Neustradamus has left

  6. Neustradamus has joined

  7. Neustradamus has left

  8. Tobias has left

  9. Kev has left

  10. Tobias

    Kev, what's on the agenda for today?

  11. Kev

    Last call's over on Correct, and I need to check Forwarding and ask for an LC on that.

  12. m&m has joined

  13. Kev

    And now I've read it.

  14. stpeter has joined

  15. stpeter

    I might be a few minutes late, bbiab

  16. Kev

    OK, ta.

  17. stpeter

    n/m I'm here

  18. Kev

    So you are.

  19. stpeter

    this is O/T for Council, but I wonder if it would be good to summarize some of the SRV experiences at jabber.org of late or file bug reports with relevant software applications -- I can do some more testing of clients that are available for Mac

  20. stpeter rereads http://xmpp.org/rfcs/rfc6120.html#tcp-resolution while he's at it

  21. Kanchil

    stpeter: http://xmpp.org/rfcs/rfc6120.html#tcp-resolution: Extensible Messaging and Presence Protocol (XMPP): Core

  22. stpeter

    Kanchil: thanks, you are so helpful!

  23. Kev

    It's nearly time.

  24. stpeter

    ah, right, so various clients aren't trying the secondary domains as mentioned in step 7 of section 3.2.1

  25. stpeter

    Kev: are we nearly there yet? ;-)

  26. ralphm has joined

  27. Kev


  28. stpeter


  29. Kev

    Poked Ralph and Matt.

  30. ralphm


  31. Kev

    1) Roll call.

  32. m&m


  33. MattJ has joined

  34. Kev

    MattJ / Tobias.

  35. Tobias


  36. MattJ


  37. Kev


  38. Kev

    2) 297

  39. Kev

    We were going to discuss LCing this but I wanted to read through it first. I've read through it.

  40. Kev

    Shall we LC it?

  41. Kev


  42. Kanchil

    Kev: http://xmpp.org/extensions/xep-0297.html: XEP-0297: Stanza Forwarding

  43. m&m

    el see it!

  44. ralphm


  45. Tobias

    looked okay to me...so +1 on LC

  46. Kev


  47. ralphm

    for the example #2, I think it would be more clear to have the xmlns as the first 'attribute'

  48. ralphm

    (of the embedded stanza)

  49. MattJ

    I'm +1 to 297

  50. MattJ

    ralphm, sure

  51. Kev

    ralphm: I don't have strong opinions either way.

  52. Kev

    But I think Matt just volunteered to change it :)

  53. ralphm

    it's more in-the-face that way

  54. Kev

    3) http://xmpp.org/extensions/xep-0308.html Last call has ended.

  55. Kanchil

    Kev: http://xmpp.org/extensions/xep-0308.html: XEP-0308: Last Message Correction

  56. ralphm

    people rarely read the prose

  57. Kev

    My reading of the LC feedback is that I should change various bits of prose, and then probably LC it again.

  58. m&m

    there are definitely some bits that need changing

  59. Kev

    Although maybe a second LC isn't needed if it's all prose changes.

  60. m&m

    it didn't seem that major to me, though

  61. m&m

    I'm fine without another LC

  62. ralphm

    there was some discussion on 'last'

  63. Kev

    I'll submit a new version in any case, and we can decide if it's worth a second LC or not.

  64. m&m


  65. Kev

    I don't promise I'll get to this immediately, other things are distracting me somewhat at the moment.

  66. ralphm

    I wasn't sure if there was consensus on that

  67. stpeter

    ralphm: consensus on 'last' or other aspects?

  68. Kev

    Last, I assume.

  69. ralphm

    stpeter: on 'last'

  70. Kev

    The protocol works fine no matter how far back you go, but I think there's a reasonable argument to be made for only supporting last correction.

  71. ralphm

    Kev: right. In the current text 'last' only occurs in the title

  72. Kev

    The first version I submitted had two disco features - for Last or Other, it wasn't entirely clear to me that there was a clear consensus to add that back in or not.

  73. Kev

    ralphm: Right, the text says to only use it for last messages as well.

  74. Kev

    I'm not overly keen on making the XEP more general if people will only ever implement Last.

  75. Kev

    I only intend implementing Last in Swift, at least.

  76. Kev

    So let's take a straw poll here, assuming everyone read the LC feedback.

  77. Kev

    Should I add Older back in, or leave it at Last.

  78. m&m

    I vote for "leave it at Last"

  79. ralphm


  80. MattJ

    Same here

  81. Tobias

    leave it at last, this is just chat and not some over-generalized protocol for non-chat things people brought up during LC

  82. ralphm

    especially because this applied to real 'chat' messages only

  83. Kev

    Excellent, ta.

  84. Kev

    4) Date of next meeting.

  85. ralphm

    for things like real-time tweets, you can fix it with item retractions in pubsub, for example

  86. m&m


  87. ralphm


  88. Kev


  89. Tobias


  90. Kev

    5) AOB

  91. ralphm


  92. ralphm

    I cannot keep up with that

  93. Kev

    ralphm: What do we need to discuss on that?

  94. MattJ


  95. m&m

    neither can I

  96. ralphm

    is there still useful discussion going on there?

  97. Kev

    There's still spec changes, so ...

  98. ralphm

    yeah, the size of the document worries me too

  99. stpeter

    I will finish the second half of my review on 301 this week

  100. Kev

    I keep wondering if I should post into one of the threads suggesting that binary XML might be a good fit for RTT.

  101. stpeter


  102. m&m


  103. m&m

    everything should be JSON

  104. Kev

    The document is somewhat out of style with other XEPs. In that it's large parts marketing rather than just telling people how to implement it.

  105. ralphm

    Kev: this

  106. m&m

    Kev: that is my main issue with it right now

  107. Kev

    I don't have firm opinions about how terrible this is.

  108. m&m

    I'm going to at least send something about section 1 before the end of tomorrow (MDT(

  109. Kev

    It's clearly (to me) undesirable - but enough to block it? Probably not.

  110. m&m

    I think it sets a bad precedent

  111. Kev

    I sent some comments about places I thought it wasn't acceptable.

  112. Kev

    I particularly dislike the name-dropping of companies who've been involved in RTT elsewhere as a means of validating the XEP.

  113. Kev

    But anyway.

  114. m&m


  115. Kev

    I've done my time on this, I feel, I've done a number of reviews and struggled through lots of threads.

  116. stpeter

    strangely I didn't take offence at any of that

  117. Kev

    I'm hoping other people will take over here and I can just do one more review when it's time to vote on Draft.

  118. m&m

    it gives me the feel of a solution in search of a problem

  119. Kev

    m&m: Oh, I believe that this is a problem worth solving.

  120. Kev

    At its heart.

  121. m&m

    I do too

  122. stpeter


  123. m&m

    but the wording, particularly in Section 1, makes it feel like the reverse

  124. Kev

    Indeed, I implemented this for Psi as custom dev work for someone many years ago.

  125. m&m

    it's trying to hard

  126. m&m


  127. Kev

    But - right.

  128. stpeter

    m&m: you need XEP-0308!

  129. m&m


  130. Kev

    You could use this for this, or this, or this, or this, and it's important because of this... it just adds verbiage without value and makes it harder to penetrate for people who want to implement it.

  131. stpeter

    anyway, 0.8 is on the way (once I finish my review), so let's see how that looks

  132. Kev

    Hurh hurgh, I said penetrate.

  133. m&m


  134. ralphm

    the other thing is FOSDEM

  135. m&m

    well, I will still endeavor to get some personal comments on section 1 before too long

  136. Kev

    m&m: Thanks.

  137. Kev

    ralphm: Where are we with that?

  138. m&m

    it seems like FOSDEM prep starts sooner and sooner each year

  139. m&m

    kind of like Christmas prep

  140. ralphm

    we have received notice of the opening of application period for a devroom

  141. ralphm

    and main track too

  142. Kev

    I do quite fancy doing Thu/Fri as XMPP and Sat as devroom and having an excuse not to turn up on Sunday this year.

  143. ralphm

    the former closes October 1

  144. ralphm

    Kev: we can definitely try getting a room on a saturday

  145. ralphm

    Kev: I'm not sure if you can actually choose, though

  146. stpeter

    regarding FOSDEM, I have been collaborating with several people about a main track about federated communications -- IM, presence, voice, video, social networking, microblogging, etc., probably with a few talks and a panel discussion of common issues and solutions

  147. Kev

    Or if we're on Sunday, Sunday FOSDEM, Mon/Tue XMPP.

  148. Kev

    So do we have any actions for Council on this? I'm assuming not, or at least not yet.

  149. ralphm

    Kev: we'll just ask them to put the federation track on the other day

  150. ralphm


  151. stpeter

    ralphm: ;-)

  152. ralphm

    The action is applying for the devroom, I guess. Although strictly this isn't a council responsibility

  153. Kev

    I assume we'll want to apply for a devroom again, although maybe this should go past Board to check.

  154. ralphm

    Hah, I've done devrooms even before there was a board

  155. stpeter

    yeah, this is the jabber/xmpp devroom -- the jabber folks kindly invite the XSF to participate ;-)

  156. ralphm

    but sure, I'll check with them

  157. Kev


  158. Kev

    So the other thing is probably the sucky state of SRV support everywhere.

  159. m&m


  160. Kev

    jabber.org's been suffering from many DDoS attacks over the last week.

  161. Kev

    I've butchered the setup so the SRV gives you first hermes.jabber.org, which is the IP being attacked (also the A for jabber.org), and then gives you fallback.jabber.org as a fallback.

  162. ralphm

    I missed the initial discussion, although I could read back, I believe Twisted's SRV connect code is broken in this respect too

  163. Kev

    But surprisingly few clients or servers seem to manage to connect, although there is a valid SRV record.

  164. m&m

    many are

  165. Kev

    In some cases this is because they just fail at SRV, and in other cases (Swift did this, although we fixed it) it timed out the entire login attempt while it was blackholing the connection to the first record.

  166. Kev

    I don't think Council has a particular action here, other than bringing it to everyone's attention that everyone sucks at XMPP.

  167. ralphm

    I think the XSF could assist in gathering information on this for the existing client implementations

  168. ralphm

    much like the dialback thing

  169. m&m


  170. ralphm

    ultimately it breaks stuff

  171. Kev

    I think it'd be great if someone took this on.

  172. Kev

    It won't be me, though, I'm suffering enough trying to deal with the jabber.org side of this crap.

  173. Kev

    It's not just clients, FWIW, servers seem to equally fail at dealing with it.

  174. stpeter nods

  175. Kev

    GTalk in particular.

  176. Kev

    Openfire too, I've been told.

  177. stpeter

    right, Openfire was failing too, as I understand it

  178. ralphm


  179. Kev

    Any client based on Smack...

  180. Kev

    There's lots, but I don't have the spare cycles to try and gather any sort of information.

  181. ralphm

    I think it even qualifies for a security notice

  182. Kev

    ralphm: I don't think it's a security issue.

  183. stpeter

    I think a message to jdev might be in order as a first step

  184. Kev

    That'd be good.

  185. stpeter

    bringing this to wider attention

  186. stpeter

    I volunteer to do that

  187. Kev

    I've been encouraging users to file bug reports when they've been telling me that it must be jabber.org that's broken.

  188. stpeter


  189. Kev

    "This client whose Jabber support hasn't been updated since 2002 isn't working and it used to. It can't be a broken client, you must have screwed up" etc.

  190. ralphm

    stpeter: awesome. It would be great to have some text on how things are supposed to work. Although the SRV RFC explains how, people seem to be confused about this.

  191. Kev

    stpeter: Thanks.

  192. ralphm

    Probably because of the lack of examples

  193. stpeter

    ralphm: yeah, something for 6120bis ;-)

  194. Kev

    Any other any other business?

  195. ralphm

    not from me

  196. Kev

    I can do minutes, but if some kind soul wants to volunteer to do them instead I wouldn't complain.

  197. m&m

    I can

  198. Kev

    Marvellous, thanks.

  199. stpeter

    thanks Matt!

  200. Kev

    I have an evening of jabber.org rubbish ahead of me.

  201. m&m


  202. Kev

    Right, I think we're done then, and over time.

  203. Kev

    Thanks all.

  204. Kev bangs the gavel.

  205. ralphm

    Kev: I'm with you in spirit

  206. Kev

    Thanks, I think.

  207. ralphm

    I happened to look over the planet.jabber.org statistics

  208. ralphm

    and noticed most of the google searches resulting in a visit have to do with jabber.org outages

  209. Kev

    Oh, GSoC!

  210. Kev

    Not a Council thing, but just to let people know that GSoC this summer was exceptionally successful.

  211. Kev

    I'm inclined to call it the best summer yet.

  212. m&m

    very nice

  213. ralphm

    Awesome work by all involved. Thank you!

  214. Kev

    We'll have another whiteboarding XEP on the table at some point, I hope, as Mateusz wrote whiteboarding for Swift using OT.

  215. ralphm


  216. Kev

    Operation(al) Transforms.

  217. Kev

    A system for resolving concurrent updates for a consistent view.

  218. Kev

    (And that's as much about it as I know :))

  219. ralphm

    isn't that the stuff used by google wave?

  220. Kev


  221. m&m has left

  222. m&m has joined

  223. stpeter

    it would be really good to settle on a whiteboarding technology

  224. stpeter

    Kev: does the Swift code go out of band?

  225. Kev

    No, it's all inband.

  226. Kev

    It's also always client-server, which is quite appealing.

  227. stpeter

    ralphm: do we need to set up an Atom feed for jabber.org again? I broke it recently :(

  228. stpeter

    Kev: multi-user or only one-to-one?

  229. ralphm

    stpeter: how did it break?

  230. Kev

    Swift's implementation's currently one-to-one, Mateusz is going to look at extending that to multi-user soon.

  231. stpeter

    ralphm: I killed our WordPress instance and converted the site to static HTML because I'm paranoid about PHP

  232. ralphm

    stpeter: having the notices in atom form would be great

  233. ralphm

    stpeter: I could then put them on the planet

  234. stpeter

    ralphm: OK, I'll do that, but just because I like you so much

  235. Kev

    But it's fine to use for multi-user, you just have many clients connecting to the server.

  236. stpeter

    Kev: ah, ok

  237. Kev

    (Where the server is just one of the clients acting as server - although you could have a specialised component)

  238. ralphm

    stpeter: (L)

  239. Kev


  240. stpeter


  241. Kev

    I've heard various complaints about SXE, I'm hoping what Mateusz has produced will be more palateable.

  242. Tobias

    Kev, does the swift code work with multiple users?

  243. Kev

    "Swift's implementation's currently one-to-one, Mateusz is going to look at extending that to multi-user soon."

  244. Tobias


  245. ralphm

    It was the last thing he sent! Maybe he 308d it

  246. ralphm


  247. m&m has left

  248. m&m has joined

  249. stpeter

    ralphm: http://www.jabber.org/atom.xml

  250. Kanchil

    stpeter: http://www.jabber.org/atom.xml: jabber.org <link rel="alternate" type="text/html" href="http://www.jabber.org/notices.html"/> <author> <name>jabber.org</name> <url>http://www.jabber.org/</url> </author> <tagline>jabber.org notices</tagline> <id>http://www.jabber.org/notices</id> <copyright>http://creativecommons.org/publicdomain/zero/1.0/</copyright> <modified>2012-08-21</modified> <entry> Another Denial of Service <link type="text/html" rel="alternate" href="http://www.jabber.org/notices.html"/> <id>tag:jabber.org,3</id> <issued>2012-08-21</issued> <modified>2012-08-21</modified> <summary>The previous DDoS attack has started again. As before, fallback measures are in place, but if your IM client doesn't handle DNS SRV records correctly then you might not be able to connect.</summary> </entry> <entry> Proposed Changes to the Service Policy <link type="text/html" rel="alternate" href="http://www.jabber.org/notices.html"/> <id>tag:jabber.org,2</id> <issued>2012-08-20</issued> <modified>2012-08-20</modified> <summary>We have posted proposed changes to the policy that governs use of the jabber.org IM service. Details, links, and instructions for providing feedback can be found in our post to the juser@jabber.org email list, see http://mail.jabber.org/pipermail/juser/2012-August/006869.html.</summary> </entry> <entry> Service Restored <link type="text/html" rel="alternate" href="http://www.jabber.org/notices.html"/> <id>tag:jabber.org,1</id> <issued>2012-08-15</issued> <modified>2012-08-15</modified> <summary>We were able to completely restore service today. However, it is quite possible that the denial of service attack could be launched again at any time. If you were unable to connect during the outage, we recommend that you consider using a different IM client or reporting a bug to the developers of the IM client you use, since standard DNS fallback and XMPP reconnection methods should have been sufficient to keep you online after the first few hours of the attack.</summary> </entry> <entry> Denial of Service

  251. stpeter


  252. stpeter

    silly Kanchil

  253. stpeter


  254. ralphm

    stpeter: did you hand craft it, or is it generated>

  255. ralphm


  256. stpeter


  257. ralphm


  258. stpeter

    old skool!

  259. ralphm

    time to bring back the xml blog code :-)

  260. stpeter

    hey I use it at stpeter.im ;-)

  261. ralphm


  262. Kev

    Interesting. Kanchil's not supposed to post anything unless the thing has a title.

  263. stpeter


  264. ralphm

    Kev: but it has a title

  265. Kev

    Let me rephrase.

  266. Kev

    It's not supposed to post anything unless it has a title, and then only the title.

  267. ralphm

    notice how it removes the tags around the titles

  268. ralphm


  269. Kev

    I expect it's just a greedy regexp where it shouldn't be, or something.

  270. ralphm

    Parsing html or xml with regexps: fail

  271. Kev

    Patches welcome.

  272. ralphm


  273. Tobias has joined

  274. m&m has left

  275. m&m has joined

  276. ralphm

    stpeter: for the October summit, are we still shooting for just the 25th?

  277. Tobias has left

  278. Tobias has joined

  279. m&m has left

  280. ralphm has left

  281. stpeter has left