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 Quite.
  28. stpeter :)
  29. Kev Poked Ralph and Matt.
  30. ralphm present
  31. Kev 1) Roll call.
  32. m&m presente
  33. MattJ has joined
  34. Kev MattJ / Tobias.
  35. Tobias here
  36. MattJ Here!
  37. Kev Marvellous.
  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 http://xmpp.org/extensions/xep-0297.html
  42. Kanchil Kev: http://xmpp.org/extensions/xep-0297.html: XEP-0297: Stanza Forwarding
  43. m&m el see it!
  44. ralphm +1
  45. Tobias looked okay to me...so +1 on LC
  46. Kev MattJ
  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 /nod
  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 yeah
  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 SBTSBC WFM
  87. ralphm +1
  88. Kev OK.
  89. Tobias wfm
  90. Kev 5) AOB
  91. ralphm 0301
  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 heh
  102. m&m haha
  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 exactly
  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 agreed
  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 *too
  127. Kev But - right.
  128. stpeter m&m: you need XEP-0308!
  129. m&m clearly
  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 exactly
  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 :-D
  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 Ta.
  158. Kev So the other thing is probably the sucky state of SRV support everywhere.
  159. m&m yarp
  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 /nod
  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 right
  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 n/p
  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 OT?
  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 Yes.
  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 (s/component/bot/)
  240. stpeter right
  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 ah..soory...overread
  245. ralphm It was the last thing he sent! Maybe he 308d it
  246. ralphm :-D
  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 sigh
  252. stpeter silly Kanchil
  253. stpeter brb
  254. ralphm stpeter: did you hand craft it, or is it generated>
  255. ralphm ?
  256. stpeter hand
  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 heh
  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 (only)
  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