XMPP Council - 2011-12-20

  1. Neustradamus has left
  2. codora has joined
  3. codora quietly sits down and waits for the council to begin.
  4. codora has left
  5. codora has joined
  6. mva has joined
  7. codora has left
  8. mva has left
  9. mva has joined
  10. Kev has joined
  11. Tobias has joined
  12. bear has joined
  13. bear has left
  14. mva has left
  15. Tobias has left
  16. Tobias has joined
  17. Tobias has left
  18. Tobias has joined
  19. linuxwolf has joined
  20. Tobias has left
  21. Tobias has joined
  22. linuxwolf has left
  23. linuxwolf has joined
  24. Tobias has left
  25. stpeter has joined
  26. stpeter meeting begins in 1 minute?
  27. Kev It does.
  28. stpeter it seems that some pokage in order :)
  29. Kev I've poked Ralph.
  30. Kev I don't see Tobias or Matt online.
  31. stpeter aha ok
  32. stpeter seems not
  33. linuxwolf /-;
  34. stpeter clearly these guys don't live by the calendar
  35. Kev Matt's just come online.
  36. MattJ has joined
  37. MattJ Sorry I'm late - someone was using my computer :)
  38. Kev The cheek.
  39. MattJ Indeed
  40. Kev Well, we have quorum.
  41. linuxwolf /whew
  42. Kev Or a quorum, probably.
  43. Kev So, assuming we're keeping last term's lateness rules in place, let's start.
  44. stpeter tweets the meeting since denting seems to be impossible at the moment
  45. Kev 1) Roll call.
  46. Kev I'm here.
  47. linuxwolf presente
  48. MattJ Here
  49. Kev 2) DMUC3
  50. MattJ Heh
  51. Kev We should really make a decision about this.
  52. linuxwolf /sigh
  53. Kev I don't like it, but I'm abstaining from a veto.
  54. Kev Have you both read this now
  55. MattJ cat fmuc.xml | sed 's/proxy/mirror/g'
  56. Kev ?
  57. stpeter :)
  58. linuxwolf I have, and yes, DMUC3 looks a lot like a FMUC
  59. MattJ Now, it *does* have some differentiating text
  60. MattJ So I'm just going to assume they used FMUC as a base as it was closest to what they wanted
  61. Kev (I note that we now have an implementation of FMUC, and I have updates to do once I'm not 'on holiday' in the new year accordingly)
  62. stpeter MattJ: so it seems
  63. MattJ But considering the end result is still somewhat the FMUC flow, I'm not sure we need another XEP doing the same thing
  64. Tobias has joined
  65. Hirotaka Sato has joined
  66. linuxwolf especially considering FMUC is still experimental
  67. MattJ I'd rather the author's feedback on why FMUC doesn't work for them, and how it can be made to work
  68. MattJ Indeed
  69. linuxwolf precisely
  70. Tobias hi
  71. Kev Hi Tobias.
  72. stpeter MattJ: true, that would be helpful
  73. Kev It turns out that FMUC is pretty easy to implement, especially in fire-and-forget mode, so I'm expecting MattJ will be implementing this in Prosody shortly after I update the XEP :)
  74. linuxwolf (-:
  75. Kev Then I'll probably call for a move to draft, as we'll have two (hopefully interopping) implementations :)
  76. stpeter FWIW, I've been having some chats with people off-list about distributed chat (e.g., doing a better job of defining the requirements)
  77. Kev But I have to drastically improve the state of the XEP before then.
  78. MattJ Kev, interestingly I already implemented it before you published the XEP :)
  79. Kev stpeter: Yes, so've I.
  80. linuxwolf so, the action on DMUC3 … reject with a request from the authors to explain what's broken in FMUC?
  81. MattJ But without the remote MUC sending just one stanza per event to the proxy
  82. Kev MattJ: So...isn't that MUC, then? :)
  83. MattJ The problem with FMUC is that it requires the primary MUC to support it
  84. Kev Ah, right.
  85. MattJ Kev, well if s2s went down, the users could still chat locally
  86. Kev Gotcha.
  87. Kev This doesn't need any extra protocol work, to do it your way.
  88. MattJ Agreed
  89. Lance Stout has joined
  90. MattJ linuxwolf, I agree
  91. Kev It doesn't cover the use cases for (F|D)MUC, though :)
  92. Kev Well, not some of them, anyway.
  93. MattJ Yep
  94. Kev linuxwolf: That seems reasonable to me.
  95. stpeter I've also reached out to the folks at http://www.cococorp.com/ -- they have an implementation of XMPP over NORM (RFC 5740) that seems to be quite interesting and I would like to make sure that anything that's defined for link-local-ish chat would work with distributed chatrooms (I have a sense that this would be the case for FMUC, but I'm not sure yet)
  96. Kev As someone abstaining :D
  97. Kev stpeter: Ok.
  98. linuxwolf ok, I'll take the responsibility of rejecting DMUC3 then (-:
  99. linuxwolf I'll get something on the list before the end of the week
  100. Kev Ta.
  101. Kev 3) http://xmpp.org/extensions/inbox/ft-metadata.html
  102. Kev I don't see any particular reason to reject this.
  103. linuxwolf no objections from me
  104. MattJ Especially when the examples mention my party
  105. MattJ +1
  106. Kev Incidentally, does anyone mind that my flow is usually: Present item Express my opinion
  107. Tobias how does it and file transfer thumbnails work together?
  108. Tobias isn't that metadata too?
  109. Kev It occurs to me that this could potentially be considered leading the discussion the way the Chair wants it.
  110. MattJ Kev, nope, go ahead :)
  111. Kev Equally, I consider you all sufficiently independent to not be put off by it ;)
  112. MattJ I pay more attention to linuxwolf, I agree with everything he says
  113. Kev Excellent.
  114. linuxwolf Kev: I'll call you out if I think there's over bias (-:
  115. Kev Tobias: It is, yes.
  116. stpeter thumbnails = http://xmpp.org/extensions/xep-0264.html
  117. linuxwolf haha
  118. MattJ +1
  119. Kev Tobias: I don't *think* it conflicts with that - do you think it does?
  120. Kev Or are you suggesting they should be rolled together?
  121. Lance Stout has left
  122. Lance Stout has joined
  123. Tobias Kev, right...the reference to the thumbnail could be included in the metadata form as a field
  124. linuxwolf I'd prefer we figure out a way to add things without rolling all of these meta-data things into one über-meta-spec
  125. stpeter yay, über-meta!
  126. linuxwolf but I'd not object to rolling everything together
  127. Kev So, what's the tone here? Accept it and extend it for other extensions, or reject for not being complete?
  128. Kev I'm on the first of these.
  129. linuxwolf especially considering that thumbnail is currently deferred
  130. linuxwolf I
  131. linuxwolf gah
  132. Tobias Kev, pidgin transfers thumbnails via bits of binary
  133. stpeter linuxwolf: it was deferred mostly because we were waiting to finish the other FT specs
  134. linuxwolf I'd accept as is, and work in extensions by draft
  135. stpeter linuxwolf: wfm
  136. Tobias right
  137. Kev Does anyone disagree with this?
  138. Tobias i'm all okay for accepting it as experimental
  139. MattJ I agree with linuxwolf
  140. Kev Cool.
  141. Kev 4) 47 to Final
  142. Kev Which I think means 47 Last Call.
  143. Kev Ahem.
  144. Kev CFI
  145. MattJ +1
  146. linuxwolf +1
  147. Tobias +1
  148. stpeter those Final XEPs are so lonely, they need some more friends...
  149. MattJ :)
  150. Kev Ok. Peter gets to issue a CFE then. Lucky Peter :)
  151. linuxwolf let's make sure every t is dotted and i is crossed, though (-:
  152. Kev (+1)
  153. Kev 5) 292 to Draft
  154. Kev I think this is premature.
  155. stpeter I won't issue the CFE until January
  156. stpeter oh yes 292 to Draft is premature, maybe I mentioned it to figure out how we can get it to Draft eventually -- sorry about that
  157. Kev We already have a widely deployed vCard standard. It's icky and may well be Wrong, but I think advancing 292 until there's implementation experience seems premature.
  158. Tobias isn't that even implemented somewhere vCard4 over XMPP?
  159. Tobias *is
  160. linuxwolf Tobias: not yet, that I'm aware of
  161. Kev Tobias: No, but if Peter says I misread his intention, we can move along :)
  162. MattJ Link Mauve has a module for Prosody, but it's experimental at the moment
  163. Tobias k
  164. Kev 5) 45 1.25.
  165. MattJ +1
  166. Kev I'd like to do this next year.
  167. linuxwolf agreed
  168. linuxwolf I need to re-read it again
  169. MattJ I read the whole thing last night... :)
  170. stpeter yeah it's rather large
  171. Kev As I'm 'on holiday' until then, and would rather not spend my time off reading all of 45.
  172. stpeter MattJ: good for you :)
  173. MattJ last "morning" night
  174. stpeter Kev: fully agree!
  175. Kev Ok. So we're agreed to discuss it next year then, fab.
  176. Kev 7) Date of next meeting.
  177. Kev January 4th, 5pm GMT?
  178. MattJ +1
  179. linuxwolf -1; other commitments
  180. Kev 11th?
  181. MattJ +1
  182. Tobias +1
  183. linuxwolf I can do 1/3 @ 17:00 UTC
  184. stpeter I'll likely be slammed on the 4th with IESG reading
  185. linuxwolf checks calendar some more
  186. MattJ stpeter, the IESG doesn't take a holiday for Christmas? :)
  187. stpeter 11th is fine with me
  188. stpeter MattJ: we do, sort of, but we have a big telechat on the 5th
  189. linuxwolf I'll have to get back to you about the 11th … I have a standing meeting at that time, but my participation is not always mandatory
  190. linuxwolf Wednesdays and Thursdays are very meeting heavy for me
  191. Kev Should we be doing a different day, then?
  192. stpeter can attest to linuxwolf's meeting madness
  193. Kev I would rather neither Monday or Friday, but Tuesday seems generally doable for me.
  194. linuxwolf I was able to do 16:00 UTC … 17:00UTC is 10:00 MST, which is when everyone else schedules their meetings /-:
  195. stpeter Tuesday is better than Wednesday for me, at least through the end of March
  196. Kev linuxwolf: Ah, so it's all Tobias's fault. That makes sense.
  197. linuxwolf Tuesdays are better, although I'd likely miss every 3rd meeting
  198. linuxwolf (-:
  199. Tobias i could do tuesdays too
  200. Kev Tuesday 3rd January 1700?
  201. linuxwolf wfm
  202. Kev (With a plan to make this the regular slot)
  203. Tobias okay
  204. MattJ +1
  205. Kev Ok.
  206. linuxwolf /whew
  207. Kev 8) Any other business?
  208. MattJ Not here
  209. stpeter although the 4th would be an appropriate date for a meeting, given that Jer released jabberd on January 4, 1999 ;-)
  210. linuxwolf so we'll celebrate the eve of the release (-:
  211. Kev Right.
  212. linuxwolf no aob from me
  213. Kev Ok, I tihnk we're done.
  214. Kev Thanks all
  215. stpeter updates the calendar
  216. Kev Consider yourselves gavelbanged.
  217. linuxwolf ouch
  218. linuxwolf (-:
  219. Tobias :)
  220. Tobias stpeter, btw: do you wheter MSFT's OAuth2 authentication for their XMPP interface is using the new OAuth SASL mechanism http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt ?
  221. Tobias i have the feeling not but i thought you might know more
  222. stpeter Tobias: I am not sure, but I can inquire
  223. stpeter I also want to find out if they have plans for s2s
  224. Tobias i mean if they decide on OAuth it'd a nice move of them to go along with that draft or if it's not what they want discuss it with the authors of that draft
  225. Lance Stout has left
  226. stpeter MattJ: thanks for the MUC notes
  227. MattJ np
  228. stpeter Tobias: indeed :)
  229. Lance Stout has joined
  230. stpeter Tobias: ok I've pinged one of my MS contacts
  231. Tobias thx
  232. stpeter goes back to reviewing the issues at http://trac.tools.ietf.org/wg/iri/trac/report/1 :(
  233. Hirotaka Sato has left
  234. ralphm has joined
  235. ralphm has left
  236. Lance Stout has left
  237. stpeter ok, that's done! :)
  238. stpeter IRIs are the bane of my existence
  239. MattJ I read "IRS" at first
  240. stpeter heh
  241. stpeter I haven't had trouble with the IRS in quite some time
  242. Zash has joined
  243. Zash has left
  244. MattJ has left
  245. linuxwolf has left
  246. linuxwolf has joined
  247. MattJ has joined
  248. linuxwolf has left
  249. linuxwolf has joined
  250. stpeter has left
  251. stpeter has joined
  252. linuxwolf has left
  253. Kev has left