XMPP Council - 2012-08-22


  1. Tobias

    Kev, what's on the agenda for today?

  2. Kev

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

  3. Kev

    And now I've read it.

  4. stpeter

    I might be a few minutes late, bbiab

  5. Kev

    OK, ta.

  6. stpeter

    n/m I'm here

  7. Kev

    So you are.

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

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

  10. Kanchil

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

  11. stpeter

    Kanchil: thanks, you are so helpful!

  12. Kev

    It's nearly time.

  13. stpeter

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

  14. stpeter

    Kev: are we nearly there yet? ;-)

  15. Kev

    Quite.

  16. stpeter

    :)

  17. Kev

    Poked Ralph and Matt.

  18. ralphm

    present

  19. Kev

    1) Roll call.

  20. m&m

    presente

  21. Kev

    MattJ / Tobias.

  22. Tobias

    here

  23. MattJ

    Here!

  24. Kev

    Marvellous.

  25. Kev

    2) 297

  26. Kev

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

  27. Kev

    Shall we LC it?

  28. Kev

    http://xmpp.org/extensions/xep-0297.html

  29. Kanchil

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

  30. m&m

    el see it!

  31. ralphm

    +1

  32. Tobias

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

  33. Kev

    MattJ

  34. ralphm

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

  35. ralphm

    (of the embedded stanza)

  36. MattJ

    I'm +1 to 297

  37. MattJ

    ralphm, sure

  38. Kev

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

  39. Kev

    But I think Matt just volunteered to change it :)

  40. ralphm

    it's more in-the-face that way

  41. Kev

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

  42. Kanchil

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

  43. ralphm

    people rarely read the prose

  44. Kev

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

  45. m&m

    there are definitely some bits that need changing

  46. Kev

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

  47. m&m

    it didn't seem that major to me, though

  48. m&m

    I'm fine without another LC

  49. ralphm

    there was some discussion on 'last'

  50. Kev

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

  51. m&m

    /nod

  52. Kev

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

  53. ralphm

    I wasn't sure if there was consensus on that

  54. stpeter

    ralphm: consensus on 'last' or other aspects?

  55. Kev

    Last, I assume.

  56. ralphm

    stpeter: on 'last'

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

  58. ralphm

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

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

  60. Kev

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

  61. Kev

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

  62. Kev

    I only intend implementing Last in Swift, at least.

  63. Kev

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

  64. Kev

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

  65. m&m

    I vote for "leave it at Last"

  66. ralphm

    yeah

  67. MattJ

    Same here

  68. Tobias

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

  69. ralphm

    especially because this applied to real 'chat' messages only

  70. Kev

    Excellent, ta.

  71. Kev

    4) Date of next meeting.

  72. ralphm

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

  73. m&m

    SBTSBC WFM

  74. ralphm

    +1

  75. Kev

    OK.

  76. Tobias

    wfm

  77. Kev

    5) AOB

  78. ralphm

    0301

  79. ralphm

    I cannot keep up with that

  80. Kev

    ralphm: What do we need to discuss on that?

  81. MattJ

    :)

  82. m&m

    neither can I

  83. ralphm

    is there still useful discussion going on there?

  84. Kev

    There's still spec changes, so ...

  85. ralphm

    yeah, the size of the document worries me too

  86. stpeter

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

  87. Kev

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

  88. stpeter

    heh

  89. m&m

    haha

  90. m&m

    everything should be JSON

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

  92. ralphm

    Kev: this

  93. m&m

    Kev: that is my main issue with it right now

  94. Kev

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

  95. m&m

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

  96. Kev

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

  97. m&m

    I think it sets a bad precedent

  98. Kev

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

  99. Kev

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

  100. Kev

    But anyway.

  101. m&m

    exactly

  102. Kev

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

  103. stpeter

    strangely I didn't take offence at any of that

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

  105. m&m

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

  106. Kev

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

  107. Kev

    At its heart.

  108. m&m

    I do too

  109. stpeter

    agreed

  110. m&m

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

  111. Kev

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

  112. m&m

    it's trying to hard

  113. m&m

    *too

  114. Kev

    But - right.

  115. stpeter

    m&m: you need XEP-0308!

  116. m&m

    clearly

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

  118. stpeter

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

  119. Kev

    Hurh hurgh, I said penetrate.

  120. m&m

    exactly

  121. ralphm

    the other thing is FOSDEM

  122. m&m

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

  123. Kev

    m&m: Thanks.

  124. Kev

    ralphm: Where are we with that?

  125. m&m

    it seems like FOSDEM prep starts sooner and sooner each year

  126. m&m

    kind of like Christmas prep

  127. ralphm

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

  128. ralphm

    and main track too

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

  130. ralphm

    the former closes October 1

  131. ralphm

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

  132. ralphm

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

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

  134. Kev

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

  135. Kev

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

  136. ralphm

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

  137. ralphm

    :-D

  138. stpeter

    ralphm: ;-)

  139. ralphm

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

  140. Kev

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

  141. ralphm

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

  142. stpeter

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

  143. ralphm

    but sure, I'll check with them

  144. Kev

    Ta.

  145. Kev

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

  146. m&m

    yarp

  147. Kev

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

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

  149. ralphm

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

  150. Kev

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

  151. m&m

    many are

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

  153. Kev

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

  154. ralphm

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

  155. ralphm

    much like the dialback thing

  156. m&m

    /nod

  157. ralphm

    ultimately it breaks stuff

  158. Kev

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

  159. Kev

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

  160. Kev

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

  161. stpeter nods

  162. Kev

    GTalk in particular.

  163. Kev

    Openfire too, I've been told.

  164. stpeter

    right, Openfire was failing too, as I understand it

  165. ralphm

    right

  166. Kev

    Any client based on Smack...

  167. Kev

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

  168. ralphm

    I think it even qualifies for a security notice

  169. Kev

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

  170. stpeter

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

  171. Kev

    That'd be good.

  172. stpeter

    bringing this to wider attention

  173. stpeter

    I volunteer to do that

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

  175. stpeter

    :)

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

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

  178. Kev

    stpeter: Thanks.

  179. ralphm

    Probably because of the lack of examples

  180. stpeter

    ralphm: yeah, something for 6120bis ;-)

  181. Kev

    Any other any other business?

  182. ralphm

    not from me

  183. Kev

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

  184. m&m

    I can

  185. Kev

    Marvellous, thanks.

  186. stpeter

    thanks Matt!

  187. Kev

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

  188. m&m

    n/p

  189. Kev

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

  190. Kev

    Thanks all.

  191. Kev bangs the gavel.

  192. ralphm

    Kev: I'm with you in spirit

  193. Kev

    Thanks, I think.

  194. ralphm

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

  195. ralphm

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

  196. Kev

    Oh, GSoC!

  197. Kev

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

  198. Kev

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

  199. m&m

    very nice

  200. ralphm

    Awesome work by all involved. Thank you!

  201. Kev

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

  202. ralphm

    OT?

  203. Kev

    Operation(al) Transforms.

  204. Kev

    A system for resolving concurrent updates for a consistent view.

  205. Kev

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

  206. ralphm

    isn't that the stuff used by google wave?

  207. Kev

    Yes.

  208. stpeter

    it would be really good to settle on a whiteboarding technology

  209. stpeter

    Kev: does the Swift code go out of band?

  210. Kev

    No, it's all inband.

  211. Kev

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

  212. stpeter

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

  213. stpeter

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

  214. ralphm

    stpeter: how did it break?

  215. Kev

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

  216. stpeter

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

  217. ralphm

    stpeter: having the notices in atom form would be great

  218. ralphm

    stpeter: I could then put them on the planet

  219. stpeter

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

  220. Kev

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

  221. stpeter

    Kev: ah, ok

  222. Kev

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

  223. ralphm

    stpeter: (L)

  224. Kev

    (s/component/bot/)

  225. stpeter

    right

  226. Kev

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

  227. Tobias

    Kev, does the swift code work with multiple users?

  228. Kev

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

  229. Tobias

    ah..soory...overread

  230. ralphm

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

  231. ralphm

    :-D

  232. stpeter

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

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

  234. stpeter

    sigh

  235. stpeter

    silly Kanchil

  236. stpeter

    brb

  237. ralphm

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

  238. ralphm

    ?

  239. stpeter

    hand

  240. ralphm

    :-)

  241. stpeter

    old skool!

  242. ralphm

    time to bring back the xml blog code :-)

  243. stpeter

    hey I use it at stpeter.im ;-)

  244. ralphm

    :-)

  245. Kev

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

  246. stpeter

    heh

  247. ralphm

    Kev: but it has a title

  248. Kev

    Let me rephrase.

  249. Kev

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

  250. ralphm

    notice how it removes the tags around the titles

  251. ralphm

    (only)

  252. Kev

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

  253. ralphm

    Parsing html or xml with regexps: fail

  254. Kev

    Patches welcome.

  255. ralphm

    :-)

  256. ralphm

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