XMPP Council - 2018-03-21

  1. Dave has left
  2. Dave has left
  3. Dave has left
  4. Dave has left
  5. Dave has left
  6. Dave has left
  7. Dave has left
  8. Dave has left
  9. Dave has left
  10. Dave has left
  11. Dave has left
  12. Syndace has left
  13. Syndace has joined
  14. Dave has left
  15. moparisthebest has left
  16. moparisthebest has joined
  17. jere has joined
  18. SamWhited has left
  19. jere has joined
  20. Dave has left
  21. jere has left
  22. Dave has left
  23. moparisthebest has left
  24. moparisthebest has joined
  25. Dave has left
  26. Tobias has joined
  27. Dave has left
  28. Dave has left
  29. ralphm has left
  30. ralphm has left
  31. Dave has left
  32. ralphm has left
  33. Tobias has left
  34. Tobias has joined
  35. Dave has left
  36. Dave has left
  37. Dave has left
  38. Dave has left
  39. Holger has left
  40. Kev has left
  41. Zash has left
  42. ralphm has left
  43. Zash has joined
  44. Dave has left
  45. Dave has left
  46. Dave has left
  47. Dave has left
  48. Dave has left
  49. ralphm has left
  50. ralphm has joined
  51. ralphm has left
  52. ralphm has joined
  53. Kev has joined
  54. Dave has left
  55. ralphm has left
  56. ralphm has joined
  57. ralphm has left
  58. ralphm has joined
  59. ralphm has left
  60. Dave has left
  61. Dave has left
  62. Dave has left
  63. Dave has left
  64. ralphm has left
  65. Dave has left
  66. Zash has left
  67. Dave has left
  68. Zash has joined
  69. moparisthebest has joined
  70. moparisthebest has joined
  71. vanitasvitae has left
  72. ralphm has left
  73. vanitasvitae has left
  74. vanitasvitae has left
  75. vanitasvitae has left
  76. Syndace has left
  77. Syndace has joined
  78. ralphm has joined
  79. Kev has left
  80. moparisthebest has left
  81. deleteme9 has joined
  82. Kev has left
  83. deleteme9 has left
  84. vanitasvitae has left
  85. vanitasvitae has left
  86. Dave has left
  87. Dave has left
  88. deleteme9 has joined
  89. Dave has left
  90. Dave has left
  91. Dave has left
  92. deleteme9 has left
  93. deleteme9 has joined
  94. Dave has left
  95. deleteme9 has left
  96. deleteme9 has joined
  97. jere has joined
  98. Dave has left
  99. Dave has left
  100. jere has left
  101. deleteme9 has left
  102. jere has joined
  103. deleteme9 has joined
  104. jere has left
  105. jere has joined
  106. deleteme9 has left
  107. deleteme9 has joined
  108. Dave has left
  109. daniel has joined
  110. jere has joined
  111. jere has joined
  112. vanitasvitae has left
  113. jere has joined
  114. jere has joined
  115. Dave has left
  116. deleteme9 has left
  117. Dave has left
  118. Dave has left
  119. Dave has left
  120. moparisthebest has left
  121. Dave has left
  122. Dave has left
  123. dwd has joined
  124. dwd In my view, you can't add a bunch of stuff about SRV fallback into XEP-0368.
  125. jonasw dwd, not even if it defines new SRV records?
  126. moparisthebest dwd, the thing is, the SRV fallback, uh, algorithm?, affects how a server admin MUST set up their records
  127. Dave has left
  128. moparisthebest as I found out the hard way, dino tries xep-368, doesn't do alpn, and does not fall back if the TCP connection succeeds
  129. moparisthebest no one using dino can use my server then
  130. jonasw moparisthebest, I’m not sure why a server operator would give ALPN-requiring SRV records high priroity though
  131. jonasw that is, preference
  132. dwd Sure, but those records are defined in RFC 6120, and not in XEP-0368. Ideally, we'd merge '368 into an RFC update, mind, but the SRV fallback strategy applies to any SRV records, not just ;368 ones.
  133. moparisthebest because I prefer them to connect that way first, it works in all my other clients :)
  134. jonasw putting them with low preference in the list would work for the case where 5222 is filtered, wouldn’t it?
  135. moparisthebest dwd, well sure but more to say 'if you implement 368, you MUST implement SRV fallback like so...'
  136. moparisthebest that wouldn't be appropriate?
  137. moparisthebest and I agree re: RFC update, but until then, it should be specified *somewhere*
  138. Zash Is there not precedent in writing down things in XEPs that are later rolled into RFC updates?
  139. Kev There is, but in this case it's something that implementing just the RFC won't be able to connect to at all.
  140. Kev We can't really have things in SRV records that connect ok at the TCP level but then fail for 6120.
  141. Ge0rG has joined
  142. jonasw Kev, they don’t fail for rfc6120
  143. jonasw because RFC 6120 doesn’t konw a thing about TLS over XMPP
  144. Kev > as I found out the hard way, dino tries xep-368, doesn't do alpn, and does not fall back if the TCP connection succeeds > no one using dino can use my server then
  145. Kev Ah, ok.
  146. Kev So this isn't SRV fallback, it's 368 fallback.
  147. jonasw Kev, yeah, but that’s because dino fails to implement xep-0368 (by adding ALPN) but still tries XEP-0368 records first.
  148. Dave has left
  149. dwd Welcome to write a SRV fallback strategy in a new XEP. Just not in '368.
  150. moparisthebest Kev, no it's SRV fallback in general, the rules are not defined
  151. jonasw moparisthebest, but technically there would be no issue to let clients prefer the 5222 method, would there?
  152. dwd Kev: It's not specific to '368 direct TLS SRV records.
  153. Holger jonasw: ALPN is a SHOULD in 0368.
  154. moparisthebest other than then they would try that first, might be a bit slower, I wouldn't prefer it
  155. jonasw moparisthebest, okay, so it’s actually a configuration issue at your side, IMO
  156. moparisthebest all I'm saying is the way you set up records depends on SRV fallback behavior, 368 or not, it just happens to matter more with 368
  157. moparisthebest or be more visible
  158. jonasw preferring a 443-multiplexing-hack over something which works with all clients seems broken to me.
  159. Dave has left
  160. ralphm has left
  161. moparisthebest so I'd probably want to put this in 368, or create a new SRV fallback XEP, and make 368 depend on it
  162. moparisthebest would the second be ok if you don't like the first?
  163. Holger Why not make ALPN a MUST?
  164. moparisthebest various reasons, still support isn't widespread, but also privacy reasons
  165. Holger (I don't like ALPN at all, but that SRV fallback seems even uglier to me.)
  166. moparisthebest ALPN support is far better in 2018 than it was in 2015
  167. moparisthebest well again SRV fallback is an issue without 368/alpn too
  168. dwd moparisthebest: Not sure that 368 needs to depend on it at all, really.
  169. Dave has left
  170. jonasw moparisthebest, how is it an issue without 368/alpn?
  171. moparisthebest just one example of many, you have multiple servers for redundancy
  172. moparisthebest and your top priority one messes up, has wrong certificate, accepts the connection but the xmpp server is messed up, any number of ways
  173. moparisthebest now nothing falls back to the other ones, oops you actually have no redundancy
  174. Holger Should we fall back if everything succeeds up to the bind request?
  175. moparisthebest I think I covered a few such scenarios in my email, I remember the BGP one :P
  176. Kev As I mentioned on list, I think, things can go wrong post-bind too.
  177. dwd Fair warning: I'm going to shut you all up in fifteen for the Council meeting, BTW.
  178. Kev Yay.
  179. moparisthebest yea I don't know the exact point we define as 'no more fallback', it seems clearer on c2s to me than s2s
  180. dwd But if somebody wants to hang about and do the minutes...
  181. dwd (Since you're all here).
  182. moparisthebest but right now it's totally ambiguous/wrong in the RFC
  183. SamWhited Please hang around and do the minutes; live minutes are the best minutes!
  184. dwd I can't do them this time; I'm on a train - and since this train gets into Paddington at 16:30, I'm on a hard stop for the meeting.
  185. moparisthebest but the general council consensus seems to be defining SRV fallback should be new xep?
  186. moparisthebest if so, I'll try to find time to work on that
  187. Kev I think a new XEP seems most appropriate here.
  188. moparisthebest that's fair, will be easiest to work out the details there too
  189. Dave has left
  190. SamWhited Having it in 0368 seems fine to me, but we probably want to work out the details somewhere else first.
  191. SamWhited Since 0368 is in draft.
  192. moparisthebest at a basic level, if you stop at TCP connection, or any place before at least validating the certificate, an attacker controlling a path to any higher priority server can prevent a successful connection, and that's wrong
  193. dwd Oooh, every device I have just told me Council's in ten minutes. How exciting.
  194. daniel has left
  195. dwd SamWhited: I'd actually like to get everything sorted in XEPs, and we'll gather them into an RFC to update RFC 6120. (As in, an RFC that updates, not an RFC that obsoletes, unless the mythic XMPP2 stuff actually happens)
  196. SamWhited That makes sense too
  197. daniel has left
  198. jere has joined
  199. SamWhited We could also combine with 0368 if/when the SRV fallback one goes to draft if it doesn't look like an RFC is going to happen.
  200. daniel has joined
  201. dwd It might *even* be worth doing this straight into an Internet Draft... We'd get review from the IETF folks on this. I was chatting to Chris Newman at the weekend about XEP-0368 anyway. (Chris did STARTTLS back in the day, and now leans toward direct TLS).
  202. Ge0rG STARTTLS always felt like a hack to me.
  203. Zash Direct TLS is the hack! :(
  204. MattJ What would you have done at the time?
  205. MattJ HTTPS spent a long time with the IP-per-host situation
  206. Ge0rG MattJ: what HTTPS did. One certificate per IP address.
  207. dwd Ge0rG: There were lots of reasons behind STARTTLS. None of them apply anymore (or the arguments are massively weakened)
  208. SamWhited Direct TLS just makes sense now that everything should be TLS… why use application level protocol negotiation to negotiate something at a lower level in the stack? Just do the lower level thing first, then do the application level thing.
  209. Ge0rG dwd: I know
  210. ralphm has joined
  211. dwd SamWhited: Sure... But back in the day, there was also Kerberos etc. It's just that now, Kerberos runs over TLS, instead of doing its own crypto.
  212. Ge0rG Now let me get started about how the CA industry and the NSA lobbied us security folks into believing that no security is better than opportunistic security.
  213. Ge0rG Or maybe we skip that for the Council meeting.
  214. Kev 'tis time.
  215. dwd 'tis time.
  216. dwd So I should warn you all that I'm on a train, therefore on a number of G's hopefully more than 3.
  217. dwd Ouch, lag.
  218. Zash Relativistic G-forces? Ouch indeed
  219. Ge0rG dwd: I can't imagine regular trains exceeding something like 1.5G
  220. dwd 1) Roll Call:
  221. dwd I'm for bacon and cheese, myself.
  222. Ge0rG bacon and cheese rolls? I'm in!
  223. dwd SamWhited, daniel?
  224. SamWhited I thought I was supposed to be the one to ask for cheese? We put cheese on (or in) everything.
  225. Kev I'm here, obviously.
  226. SamWhited I guess I'll have to ask for kippers just to even things out.
  227. dwd OK, I don't see daniel but maybe he'll join us later.
  228. dwd 2) Advance XEP-0066 to Final
  229. Ge0rG It looks like there was some major resistance to that.
  230. Kev It's not clear to me that we have satisfied the implementation requirements, even ignoring all the other issues onlist :)
  231. dwd I think I'm -1 on this, I don't think it meets the implementation criteria.
  232. Kev So I don't think it even needs a Council vote, I don't think it meets requirements for us to vote.
  233. dwd Votes, please?
  234. Kev But if it did, I'd be -1.
  235. daniel has left
  236. Ge0rG -1
  237. Ge0rG I still think 66 is a good candidate for the "take the best parts and run" approach suggested some Meetings ago
  238. dwd Kev: I'm actually unclear who decides the implementation criteria, so I shall assume that's for us to veto if we believe it doesn't.
  239. dwd SamWhited: Any vote?
  240. SamWhited It seems "good enough" to me, I'm +1. Although with the note that there is a bit of awkwardness and I agree that "take the best parts and run" sounds good too.
  241. dwd 3) Advance XEP-0048 to Final
  242. Ge0rG -1
  243. dwd Note there is a competing proposal in bookmarks2, we're voting on that later.
  244. dwd I'm -1 to advance, I'd rather move this to historical again.
  245. SamWhited +1 to freeze 0048 and new work can go into bookmarks2
  246. Kev Again, this wasn't clear that there are two independent implementations of what's specced in this version. Plus assorted issues with it.
  247. Kev (-1)
  248. SamWhited Although I also agree that this could be historical.
  249. Ge0rG SamWhited: freeze as final or as historical?
  250. SamWhited Freeze as in final, but if we want to have a historical vote I'd +1 that either way.
  251. dwd 4) Adopt Proposal "Bookmarks 2 (This Time it's Serious)"
  252. Ge0rG I'd like to see where Bookmarks2TTiS leads
  253. Kev Aside: I'd be in favour of revert 48 to iq:private, and make it Historical, and advance bookmarks2 in PIP.
  254. SamWhited +1 assuming "adopt" means "accept as experimental"
  255. Kev +1
  256. Ge0rG +1 to what Sam said
  257. dwd For the record, I'm happy if this changes title, but it'd be good if we changed '48's title at the same time...
  258. dwd ALso +1.
  259. dwd (Obv)
  260. Kev Suggestion: Change 48 to Bookmarks in Private Storage, and change TTiF to Bookmarks in Pubsub or something.
  261. Kev If we want to change titles.
  262. SamWhited I would be -1 to reverting it to private storage.
  263. Kev Even while also changing it to historical (documenting what's in place), when it's what's in place and PIP isn't?
  264. dwd SamWhited: Seems that's what's implemented, mind.
  265. dwd 5) XEP-0050 Ad-Hoc Commands: Clarify 'execute' actions equivalence.
  266. Kev There is a fundamental choice her.
  267. Kev There is a fundamental choice here.
  268. dwd This is PR #591 by the way.
  269. dwd And there is *also* #598 which competes.
  270. Kev Either change the text to be clear that there's a bad state, which is a clarification, or change the text to be sensible and avoid the bad state.
  271. Kev Flow's is the technically better change, I think, but is a breaking change to xep50.
  272. Kev Mine is just clarifying that if you do something in particular, you're being stupid.
  273. dwd Kev: Breaking in theory or practise?
  274. Kev dwd: This conversation came about because of people doing silly things. So I think in practice.
  275. Kev Although possibly not in an untenable way.
  276. Ge0rG Wouldn't it be better to fix things in practice then?
  277. Kev Ge0rG: Well, that's why my text explains that doing this is broken. Which it always has been, people just don't realise.
  278. Kev I'm -1 on Flow's PR as-is, because I think it needs to explain the breaking change, but I could be persuaded either way on the basic approach. Noting that breaking changes to Draft XEPs we should be trying to avoid.
  279. Ge0rG Kev: if people didn't realize that, they probably never ran into the issue so fixing the XEP to have a better behavior won't make them run into even more things?
  280. SamWhited I'm +1 to flows change, but also agree that an explanation would be useful.
  281. Kev SamWhited: What's the justification here for a breaking change to a Draft XEP?
  282. dwd Hmmm. So I think I'm +1 on one of these, but I'm not sure I care which...
  283. Kev I think I can be persuaded about making the breaking change, but I don't think I am yet.
  284. dwd Kev: I'm not sure what this change is breaking. I mean, it means something works which previously did not.
  285. Kev dwd: It means behaviour will change.
  286. Ge0rG dwd: people following the "new" XEP could run into broken servers
  287. dwd Ge0rG: Ah, good point.
  288. Kev Where previously an illegal state would prevent you doing anything other than cancel, now it'll silently succeed in doing something that it wouldn't before.
  289. Ge0rG so I'm +1 if we add a note similar to what we did in 0045 last week
  290. Ge0rG I'm not insisting on a feature though.
  291. dwd Kev: I think that's a stretch for a claim this is breaking, though.
  292. Kev I think if you change the required behaviour of entities, that's a breaking change.
  293. dwd Yeah, I think I'm +1 on both of these.
  294. SamWhited It seems worth cleaning this up, and since it doesn't seem like it would be the end of the world we might as well do it right.
  295. Kev Oh, wait wait.
  296. Kev I think both PRs might actually be wrong.
  297. dwd I'm waiting.
  298. Kev Because execute is used for setting a default.
  299. dwd You're going to veto your own PR?
  300. Kev So in Flow's case, I think this change means that where it was previously possible to set 'no default', now it forces a default to be set.
  301. Kev And in my case where I claim it's not a legal state, actually it is saying that there's no default action.
  302. Kev Except that's also contradictory.
  303. dwd Hmmmm.
  304. Ge0rG Now I'm completely lost.
  305. Kev Ge0rG: exactly
  306. Kev I propose
  307. dwd So in this case I'll change my vote to no vote, and can you take this to the list.
  308. dwd Anyone voting on this one?
  309. Ge0rG Kev: ELI5 on-list please.
  310. Kev We -1 both of these PRs now, and we each commit to reading this bit of the XEP *in detail* until we understand it properly, and then discuss properly next week.
  311. SamWhited yah, I'll also go on list since this wasn't my understanding
  312. SamWhited I'll re-read and make sure I didn't interpret something wrong.
  313. Kev Because I spent a good chunk of time on this and I think I got it slightly wrong last time.
  314. Ge0rG Kev: feel free to collaborate with flow so that you prepare a single PR :)
  315. dwd Ge0rG: SamWhited: You vetoing or what? I'm completely lost now.
  316. Kev This is a badly defined bit of spec.
  317. Kev I am -1 to both for now.
  318. dwd Kev: Badly specified bit of definition.
  319. SamWhited dwd: I am on list.
  320. Ge0rG dwd: on-list as well
  321. dwd Cool. For the next one too?
  322. Ge0rG Yes.
  323. SamWhited Yes, sorry, for both of these PRs.
  324. Kev Yes, on-list might work for me too, I guess, default to -1 if I don't reply :)
  325. Ge0rG Kev: is that a -0.5?
  326. dwd 7) XEP-0223: Add a warning about publish-options support https://github.com/xsf/xeps/pull/608
  327. Kev Peter always liked it when Isode folks disagreed on list. I wonder what he thinks of Isode folks disagreeing with their own PRs :)
  328. Kev +1
  329. dwd This seems like a +1
  330. Ge0rG the PR comes with a notice about making discovery a MUST.
  331. Ge0rG Can we vote on that too?
  332. dwd Kev: I've rejected my own protoXEP once. I think I beat you. (So has Peter, mind)
  333. SamWhited +1
  334. Ge0rG +1
  335. Kev dwd: Yes, but that was a protoXEP, I don't remember anyone doing it for a PR (but might have).
  336. Kev As a note to Editor, PEP needs to change to Pubsub in this PR before merge, I think.
  337. Kev This isn't storing anything in PEP.
  338. SamWhited oh good point; add a note on the PR?
  339. jonasw Kev: put that on the pr please
  340. Kev (Meaning is clear, but terminology is wrong, commenting now)
  341. dwd OK, I'm changing my mind and vetoing - yeah, I prefer MUST check discovery and I'm find with changing it to Pubsub.
  342. Kev I'm fine with just giving a provisional +1 to the PR after SHOULD/MUST and PEP/Pubsub, if that speeds things along.
  343. Kev dwd: You?
  344. Ge0rG dwd: couldn't you "+1 under the following conditions" instead?
  345. dwd Well, probably. But I'll hold a veto on it to make sure it happens. :-)
  346. SamWhited I also prefer MUST, I figured we might as well go ahead and merge this, but if a pr changing the wording can happen quickly that's fine too.
  347. dwd But yeah, I'll change to a +1 the moment the MUST happens.
  348. dwd 8) Next Meeting
  349. Ge0rG +1W?
  350. dwd I have a feeling that Europe changes timezone at the weekend, is that right?
  351. Zash Yes
  352. Ge0rG rumors!
  353. Kev Yes, Sunday at 1AM
  354. Kev Which is great news for those of us running a 10K Sunday morning.
  355. dwd Shall we shift it to 1500Z in that case for next week? (Sorry SamWhited).
  356. Kev Yes, please.
  357. Ge0rG So it will "move" to 1700 CEST?
  358. dwd Everyone else in agreement? (Just keeping it at the same time next week for Europeans, and messing Sam about)
  359. dwd Ge0rG: Erm. Yes?
  360. SamWhited I will most likely be getting off the bus at that time, so I'll be late probably
  361. Ge0rG +1
  362. SamWhited 15:15Z would probably be better, if we could do that.
  363. Kev That'd work for me next week.
  364. dwd OK, 1515Z then. I'm fine with that.
  365. dwd 9) AOB
  366. dwd Hopefully not because we're coming into Paddington.
  367. Ge0rG +1 for 1515Z
  368. Ge0rG I wanted to vote on abolishing Pidgin.
  369. dwd Ge0rG: Hmmm.
  370. jonasw ceterum pidgin delendam esse
  371. jonasw *ceterum censeo
  372. dwd Assuming none, or at least nothing serious...
  373. dwd 10) Ite, Meeting Est.
  374. dwd Thanks all.
  375. Kev Thanks all.
  376. Ge0rG I feel cheated now. I was told we can vote on *anything*!
  377. dwd (If nobody else is writing minutes, I'll get to them... eventually.)
  378. dwd Ge0rG: Yes, but not every vote will have any effect...
  379. Ge0rG dwd: sometimes it is purely about the signals we send and not about actual actions.
  380. dwd has left
  381. Ge0rG Thanks, though :)
  382. SamWhited Motion for all XSF business to be conducted in Latin from now on.
  383. Ge0rG Motion to change "Latin" to "Latin-15"
  384. Ge0rG Motion to change "Latin" to "Latin-9"
  385. Dave has left
  386. moparisthebest utf-16 with a BOM ?
  387. Zash Motion to deprecate the letter U
  388. Zash No need for U when we have V
  389. moparisthebest ooh can you abolish BOMs
  390. Zash Don't yov agree?
  391. Kev Zash: But we don't have V.
  392. Ge0rG Obligatory reference to http://grammar.ccc.commnet.edu/grammar/twain.htm
  393. Kev (Welsh doesn't have K, V, X or Z)
  394. SamWhited Or vowels, apparently.
  395. Ge0rG Now someone needs to make a cheap pun on the pronunciation of I, U and V.
  396. moparisthebest but re: starttls discussion I missed pre-meeting, it was 100% the correct way to go at the time, in my opinion
  397. SamWhited I love that possibly-Twin thing, I wonder if that was the inspiration for Guy Steel's "Growing a Language" talk (which is fantastic and you should watch it): https://www.youtube.com/watch?v=_ahvzDzKdB0
  398. moparisthebest in fact it seems to me IANA basically required it at the time for port assignments and such?
  399. SamWhited possibly-Twain, even.
  400. moparisthebest and today, it's worse than useless and everything should just be direct TLS, just something that changed meh
  401. Ge0rG moparisthebest: STARTTLS always was a dirty hack. It just happened to be the only viable dirty hack for some years
  402. moparisthebest yes, the only viable and officially IANA/IETF sanctioned hack
  403. Dave has left
  404. Dave has left
  405. jere has joined
  406. Dave has left
  407. Lance has joined
  408. Dave has left
  409. Lance has left
  410. Dave has left
  411. Dave has left
  412. Dave has left
  413. Dave has left
  414. Dave has left
  415. Dave has left
  416. Dave has left
  417. Dave has left
  418. Dave has left
  419. Dave has left
  420. Dave has left
  421. daniel has left
  422. Dave has left
  423. ralphm has left
  424. moparisthebest has left
  425. Dave has left
  426. Dave has left
  427. vanitasvitae has left
  428. Dave has left
  429. vanitasvitae has left
  430. vanitasvitae has left
  431. daniel has left
  432. Dave has left
  433. daniel has joined
  434. Dave I'm actually sitting next to its author now.
  435. Dave Chris recently wrote an I-D saying its time was passed, I think.
  436. Zash Wait wasn't IETF last week? Or is it now?
  437. Dave Now. I'm in the plenary.
  438. Zash My sense of time is weird.
  439. Dave Started last Saturday, mind.
  440. moparisthebest I thought I read that but can't find it now, all I can find is a lone blog post https://www.agwa.name/blog/post/starttls_considered_harmful
  441. jonasw has left
  442. moparisthebest has joined
  443. daniel has left
  444. Dave has left
  445. daniel has joined
  446. Dave has left
  447. Dave has left
  448. Tobias has joined
  449. ralphm has joined
  450. dwd has joined
  451. dwd has left
  452. dwd has joined
  453. Dave has left
  454. Zash has left
  455. dwd has left
  456. Zash has left
  457. Dave has left
  458. moparisthebest has left
  459. Dave has left
  460. Dave has left
  461. Dave has left
  462. Dave has left
  463. Dave has left
  464. Dave has left
  465. Dave has left
  466. Dave has left
  467. Dave has left
  468. Dave has left
  469. Dave has left
  470. Dave has left
  471. Dave has left
  472. Dave has left
  473. Dave has left
  474. Dave has left
  475. Dave has left
  476. Dave has left
  477. Dave has left
  478. Dave has left
  479. Dave has left
  480. Dave has left
  481. Syndace has left
  482. Dave has left
  483. Dave has left
  484. Dave has left
  485. Dave has left
  486. Dave has left
  487. Dave has left
  488. Dave has left
  489. Dave has left
  490. Dave has left
  491. Dave has left
  492. Dave has left
  493. Dave has left
  494. Syndace has joined
  495. Dave has left
  496. Dave has left
  497. Dave has left
  498. Holger has joined
  499. Holger has left
  500. Holger has joined
  501. Tobias has joined
  502. Holger has left
  503. SamWhited has left
  504. daniel has left
  505. daniel has joined
  506. ralphm has joined
  507. vanitasvitae has left
  508. jere has joined
  509. Zash has left
  510. jere has left
  511. jere has joined
  512. Dave has left
  513. Dave has left
  514. Dave has left
  515. Dave has left
  516. Dave has left
  517. vanitasvitae has left
  518. Dave has left
  519. Dave has left
  520. Dave has left
  521. Dave has left
  522. Dave has left
  523. Dave has left
  524. Dave has left
  525. Dave has left
  526. Dave has left
  527. Dave has left
  528. Dave has left
  529. Dave has left