XSF logo XMPP Council - 2011-11-09


  1. ralphm has left
  2. linuxwolf has joined
  3. stpeter has joined
  4. Zash has joined
  5. Florob has joined
  6. MattJ has joined
  7. Florob has left
  8. Florob has joined
  9. Florob has left
  10. Florob has joined
  11. dwd has joined
  12. MattJ needs to implement POKE so someone can wake him if he falls asleep during the meeting
  13. stpeter :)
  14. linuxwolf step 1: build a robot
  15. MattJ Accomplished
  16. Kev Right, I'm here now, let's see if I can remember to be here in 20 minutes. I'd completely forgotten until I sat down at my machine.
  17. linuxwolf heh
  18. MattJ Kev, don't worry, I'm here trying to read XEPs and stay awake
  19. Kev I managed to read them earlier.
  20. stpeter MattJ: those will put you to sleep!
  21. MattJ Indeed they are
  22. MattJ It's been a long day
  23. dwd MattJ, I think you'll find the days are actually getting quite short, now.
  24. MattJ Longer and longer for me
  25. dwd MattJ, Are you moving close to the speed of light?
  26. MattJ Working on it
  27. MattJ I feel like I've been fired through a collider if that's what you're wondering
  28. linuxwolf I think the constants of time won't be applying to me for the rest of the year
  29. dwd I misread that as colander.
  30. linuxwolf haha
  31. dwd Assumed that MattJ was feeling drained.
  32. Kev The colander of time?
  33. dwd Or perhaps strained.
  34. dwd It just opens up a whole vein of bad puns, doesn't it?
  35. linuxwolf Yes. Yes it does.
  36. MattJ groans
  37. dwd feels *so* proud.
  38. stpeter yay, got my inbox under 1500 messages
  39. MattJ dwd, for a series of puns based on something I didn't say? :)
  40. linuxwolf did you unsub from 82attendees@ietf.org? (-;
  41. MattJ dwd, your standards are slipping
  42. dwd stpeter, Unrecoverable storage failure?
  43. dwd MattJ, These are my standards, and if you don't like them, I have others.
  44. stpeter dwd: I wish
  45. stpeter I do see Ralph online, shall I ping him?
  46. Kev Can do, I did so a couple of minutes ago.
  47. stpeter ok
  48. ralphm has joined
  49. Kev Hola.
  50. Kev Right, are we sitting comfortably? Then let's begin.
  51. Kev 1) Call for assorted baked products.
  52. Kev I'm here.
  53. MattJ took a moment to figure that out
  54. linuxwolf 目前
  55. MattJ I'm here, in body at least
  56. stpeter linuxwolf: nice!
  57. Kev And assuming Ralph's join indicates he's here, let's continue.
  58. Kev 2) Account management.
  59. ralphm I'm couch surfing
  60. Kev We said we'd ~vote on accepting this once we'd had community feedback and the author had responded.
  61. Kev I saw a number of comments suggesting this was not the right approach, and I don't remember any in support of it; is that about right?
  62. linuxwolf correct
  63. linuxwolf even a call to move (part of) this to another venue
  64. Kev For my part, I've got two main concerns with it:
  65. Kev 1) Using stream features for this is Wrong. 2) The XSF can't be the appropriate place to develop a new security model.
  66. linuxwolf /nod
  67. stpeter #2 is rather significant
  68. Kev I might be persuaded to let it through if just 1) was the problem, but when 2) is in the same document, I don't think we can even put it on the vine.
  69. linuxwolf my thoughts exactly
  70. MattJ I think that makes sense
  71. ralphm I agree
  72. MattJ If we're going to rework all the clients and servers to use a new IBR protocol (when the current one is working ok for most purposes) then we should make sure we go about it properly
  73. Tobias has joined
  74. ralphm we can use security models or promote the development of them
  75. ralphm but we need Those Guys™
  76. Kev So I think my suggestions for the author are to 1) look at a more appropriate way of managing user accounts than stream features (the suggestion of first binding with ANONYMOUS and then doing something quite like iq:register sounds right to me). 2) Look at getting the new security model standardised through the IETF, so a XEP can work off the base of people who know more about this than the XSF.
  77. Kev I'll write a mail saying as much when I do the minutes.
  78. Kev I'm reading this as everyone being -1, is that correct?
  79. linuxwolf /agreed
  80. MattJ +1 2 -1
  81. MattJ (I know, I'm approaching dwd's standards)
  82. Kev That's asserting that dwd *has* standards...
  83. MattJ True
  84. Kev Moving on then.
  85. Kev 3) XEP-0258
  86. Kev Kurt's updated this, and would like us to vote on moving it to Draft
  87. MattJ You need to include names :)
  88. MattJ Oh, yes
  89. Kev (Although he made it clear he only wanted it voted on if the vote was going to pass it :))
  90. ralphm Kev aw!
  91. MattJ Kev, oh, that's that then... :)
  92. linuxwolf I guess he doesn't play the lottery much (-;
  93. MattJ Well, it all seems fine to me... I don't know the current implementation status of the new version though
  94. Kev Anyway, we've got this implemented in Swift, and the other we have this implemented in M-Link.
  95. dwd linuxwolf, He does, he only plays if he's certain to win, though.
  96. MattJ Ok
  97. Kev And it seems to work ok.
  98. dwd Kev, Two implementations, strangely, for Gajim.
  99. MattJ Well I'm +1 to draft
  100. Kev (So I'm +1)
  101. Kev linuxwolf / ralphm?
  102. dwd Kev, Also Prosody server-side. RUmour of another XEP-0258 client or two soon, as well.
  103. ralphm surprising
  104. ralphm .
  105. ralphm hmm, major lag for some reason
  106. MattJ wfm
  107. ralphm I am +1
  108. linuxwolf I'm tempted to vote −1 on the principle of risk assessment (-:
  109. linuxwolf but I am +1
  110. Kev Marvellous.
  111. Kev 4) http://xmpp.org/extensions/inbox/correction.html
  112. MattJ +1
  113. linuxwolf I'll give Kurt a stern look next time I see him
  114. Kev (I'm in favour, natch)
  115. MattJ A XEP by any other name would be the same protocol, FWIW
  116. ralphm apparently dwd had such a nightmare on this he couldn't articulate it
  117. Kev MattJ: Right, I think we can quibble about names when it's on the vine.
  118. linuxwolf I am still concerned about the change of any arbitrary past message
  119. Kev linuxwolf: Which is why it says not to do that.
  120. dwd ralphm, Only with changing arbitrary past messages.
  121. ralphm I think it is a terrible feature for recognise that some people want it and don't object to the spec being experimental
  122. ralphm dwd: I forgot my sarcasmicon again?!
  123. linuxwolf wow…lag and burst
  124. Kev For those not keeping up, this version (unlike the version I put up an age ago) is correcting the most recent message only :)
  125. linuxwolf I've no objections to publishing
  126. stpeter noted :)
  127. Kev Excellent.
  128. Kev 5) The bas64 stuff in XEP9.
  129. Kev I'm +1
  130. linuxwolf but I don't see text saying a client MUST NOT correct a message that is not it's own
  131. ralphm +1
  132. ralphm linuxwolf: wait what?
  133. Kev linuxwolf: Ok, I'm happy to tidy that up. It explicitly says that you send this to correct the most recently sent message.
  134. linuxwolf lag
  135. linuxwolf gawdamit
  136. ralphm linuxwolf: how would that work anyway?
  137. linuxwolf I'll save any further comments until I see xep-correct on the list (-:
  138. linuxwolf re XEP-009 … +1
  139. MattJ +1
  140. MattJ I somehow missed Kev's two XEP-0009 messages
  141. MattJ I thought linuxwolf's lag was going into reverse
  142. Kev 6) XEP-0068 v1.2 http://xmpp.org/extensions/tmp/xep-0068-1.2.html http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2pre1
  143. linuxwolf mindlag (-:
  144. MattJ Wait, where did this come from? :)
  145. Kev So, I missed the RFC leading up to this, and I don't really like it, so I need to go do some list reading, I think.
  146. ralphm heh
  147. stpeter no hurry
  148. ralphm I did read it, and this would be a possible conclusion
  149. stpeter see http://mail.jabber.org/pipermail/standards/2011-October/025341.html
  150. MattJ It's an RFC already? Or still a draft?
  151. stpeter etc.
  152. Kev I'd like to just pass this off to the next Council instead.
  153. ralphm I'm still wondering about suggesting a way to avoid conflict (in case no registration takes place), in the distributed extensibility sense
  154. stpeter Kev: sure
  155. Kev MattJ: I use the common term, not the right term :)
  156. MattJ Ok :)
  157. MattJ I thought stpeter might be fast-tracking his own documents for a moment :)
  158. stpeter MattJ: should go to Working Group Last Call at the IETF a few weeks from now, I'd expect
  159. Kev 7 http://xmpp.org/extensions/inbox/muc-unique.html
  160. stpeter as I said, no hurry
  161. MattJ Sigh, I'm still torn on this...
  162. linuxwolf I'm ambivalent
  163. MattJ I guess I think overall it should be published, mainly because it already has implementations
  164. ralphm I did like the suggestion of something like clark's notation, not the one form to rule them all
  165. MattJ A kind of non-historical historical
  166. linuxwolf right
  167. Kev So, are we publishing?
  168. MattJ Nobody has to use or implement it if they don't want to
  169. MattJ But people have
  170. ralphm MattJ: are those implementation using that unauthorized namespace?
  171. MattJ So yes, publish
  172. MattJ The what what?
  173. ralphm http://jabber.org/protocol/muc#unique
  174. linuxwolf no objections to publishing
  175. MattJ ralphm, why is it unauthorized?
  176. MattJ Prosody uses 'http://jabber.org/protocol/muc#unique' it seems, yes
  177. ralphm because, you know, it isn't a XEP yet, it is a new namespace and we use different ones now?
  178. Kev ralphm: It is a XEP, it's in XEP-0045.
  179. ralphm just asking. If there already is deployment, well, yeah
  180. Kev This is splitting it out.
  181. MattJ Well, that's my point about it being semi-historical
  182. stpeter we're just moving things around
  183. Kev http://xmpp.org/extensions/xep-0045.html#schemas-unique
  184. Kev Five minutes to go and lots still to do. I don't want the last meeting of term running over!
  185. ralphm erm, I missed that, sorry
  186. Kev ralphm: Are you ok on publishing?
  187. ralphm +1 then
  188. Kev Excellent.
  189. linuxwolf pubit!
  190. Kev 8) http://xmpp.org/extensions/inbox/dmuc3.html
  191. ralphm we need more of those!
  192. ralphm distribute them all
  193. MattJ I haven't submitted mine yet!
  194. linuxwolf DISTRIBUTE ALL THE THINGS!
  195. Kev This is an odd one. It seems to be taking the approach from FMUC, including copy/pasting blocks of the text from FMUC, but trying to publish it under a new author, with slightly different syntax.
  196. ralphm mattj: we'll reserve dmuc4 for you!
  197. MattJ Thank you
  198. MattJ I heard my next door neighbour wants to submit one too
  199. stpeter Kev: yeah, I think the author might want to simply post to the list -- perhaps it didn't even belong in the inbox
  200. MattJ Can he have dmuc5?
  201. linuxwolf focus please
  202. MattJ linuxwolf, I'm focusing hard
  203. ralphm Kev: can't we suggest he works with the fmuc people?
  204. Kev ralphm: We can, that's me.
  205. linuxwolf (-:
  206. ralphm Kev: I know, this is you other hat, you know?
  207. Kev But I don't mind this going onto the vine, we've got 3 other variants up there already :)
  208. ralphm well, if it is mostly a copy I'm -1
  209. Kev ralphm: I think you should decide for yourself rather than using my biased summary :)
  210. MattJ Same, but I haven't read it, so if it's any more complicated I'm voting on list
  211. MattJ I'll vote on list
  212. Kev Ok, let's leave this clean and just leave it for the next Council, then.
  213. ralphm Kev: that was my plan
  214. Kev Rather than having the confusion of voting crossing the term end.
  215. MattJ Good point
  216. Kev I think that's everything, so:
  217. Kev 9) Thanks folks.
  218. ralphm And thank you, Kev for chairing
  219. Kev Thanks all for the hard work.
  220. MattJ Thank you :)
  221. stpeter hear hear!
  222. MattJ 20s left
  223. Kev 10) Any other business
  224. ralphm beers, fireworks
  225. Kev (Lasting less than 10 seconds)
  226. MattJ None
  227. linuxwolf nay
  228. dwd Oh, one more thing
  229. ralphm :-D
  230. dwd Why do these meetings take so long?
  231. linuxwolf shoots evil eye @ dwd
  232. dwd cackles.
  233. Kev 11) Fini.
  234. linuxwolf 再见
  235. Kev Thanks folks, see you on the lists, good luck to the next Council.
  236. MattJ +1
  237. stpeter thanks indeed
  238. Kev I will sort out minutes, but not tonight.
  239. linuxwolf 谢谢大家
  240. MattJ Oh yes, thanks for humouring me with the late meeting :)
  241. ralphm linuxwolf: care to translate?
  242. linuxwolf thank you to everyone?
  243. linuxwolf practicing my copy/paste Chinese (-:
  244. ralphm MattJ: It's ok! I will now go sleep
  245. MattJ linuxwolf, with a question mark because you're not quite sure? :)
  246. MattJ 'night ralphm :)
  247. stpeter goes back to reviewing IRI WG issues
  248. linuxwolf MattJ: precisely
  249. MattJ stpeter, some people get all the fun
  250. ralphm IRItating?
  251. linuxwolf goes to read more JOSE drafts
  252. stpeter enjoy :)
  253. linuxwolf I kinda wish it was called JOES
  254. linuxwolf (-:<
  255. ralphm linuxwolf: just buy some stickers
  256. ralphm use funky fonts
  257. ralphm ...
  258. ralphm profit!
  259. linuxwolf heh
  260. linuxwolf maybe I can get ekr to raise a "point of order" on the WG name (-:
  261. ralphm I'm sure you could
  262. ralphm should be fun
  263. linuxwolf /nod
  264. Florob has left
  265. ralphm has left
  266. Tobias has left
  267. MattJ has left
  268. linuxwolf has left