XMPP Council - 2011-12-20

  1. codora quietly sits down and waits for the council to begin.

  2. stpeter

    meeting begins in 1 minute?

  3. Kev

    It does.

  4. stpeter

    it seems that some pokage in order :)

  5. Kev

    I've poked Ralph.

  6. Kev

    I don't see Tobias or Matt online.

  7. stpeter

    aha ok

  8. stpeter

    seems not

  9. linuxwolf


  10. stpeter

    clearly these guys don't live by the calendar

  11. Kev

    Matt's just come online.

  12. MattJ

    Sorry I'm late - someone was using my computer :)

  13. Kev

    The cheek.

  14. MattJ


  15. Kev

    Well, we have quorum.

  16. linuxwolf


  17. Kev

    Or a quorum, probably.

  18. Kev

    So, assuming we're keeping last term's lateness rules in place, let's start.

  19. stpeter tweets the meeting since denting seems to be impossible at the moment

  20. Kev

    1) Roll call.

  21. Kev

    I'm here.

  22. linuxwolf


  23. MattJ


  24. Kev

    2) DMUC3

  25. MattJ


  26. Kev

    We should really make a decision about this.

  27. linuxwolf


  28. Kev

    I don't like it, but I'm abstaining from a veto.

  29. Kev

    Have you both read this now

  30. MattJ

    cat fmuc.xml | sed 's/proxy/mirror/g'

  31. Kev


  32. stpeter


  33. linuxwolf

    I have, and yes, DMUC3 looks a lot like a FMUC

  34. MattJ

    Now, it *does* have some differentiating text

  35. MattJ

    So I'm just going to assume they used FMUC as a base as it was closest to what they wanted

  36. 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)

  37. stpeter

    MattJ: so it seems

  38. MattJ

    But considering the end result is still somewhat the FMUC flow, I'm not sure we need another XEP doing the same thing

  39. linuxwolf

    especially considering FMUC is still experimental

  40. MattJ

    I'd rather the author's feedback on why FMUC doesn't work for them, and how it can be made to work

  41. MattJ


  42. linuxwolf


  43. Tobias


  44. Kev

    Hi Tobias.

  45. stpeter

    MattJ: true, that would be helpful

  46. 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 :)

  47. linuxwolf


  48. Kev

    Then I'll probably call for a move to draft, as we'll have two (hopefully interopping) implementations :)

  49. 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)

  50. Kev

    But I have to drastically improve the state of the XEP before then.

  51. MattJ

    Kev, interestingly I already implemented it before you published the XEP :)

  52. Kev

    stpeter: Yes, so've I.

  53. linuxwolf

    so, the action on DMUC3 … reject with a request from the authors to explain what's broken in FMUC?

  54. MattJ

    But without the remote MUC sending just one stanza per event to the proxy

  55. Kev

    MattJ: So...isn't that MUC, then? :)

  56. MattJ

    The problem with FMUC is that it requires the primary MUC to support it

  57. Kev

    Ah, right.

  58. MattJ

    Kev, well if s2s went down, the users could still chat locally

  59. Kev


  60. Kev

    This doesn't need any extra protocol work, to do it your way.

  61. MattJ


  62. MattJ

    linuxwolf, I agree

  63. Kev

    It doesn't cover the use cases for (F|D)MUC, though :)

  64. Kev

    Well, not some of them, anyway.

  65. MattJ


  66. Kev

    linuxwolf: That seems reasonable to me.

  67. 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)

  68. Kev

    As someone abstaining :D

  69. Kev

    stpeter: Ok.

  70. linuxwolf

    ok, I'll take the responsibility of rejecting DMUC3 then (-:

  71. linuxwolf

    I'll get something on the list before the end of the week

  72. Kev


  73. Kev

    3) http://xmpp.org/extensions/inbox/ft-metadata.html

  74. Kev

    I don't see any particular reason to reject this.

  75. linuxwolf

    no objections from me

  76. MattJ

    Especially when the examples mention my party

  77. MattJ


  78. Kev

    Incidentally, does anyone mind that my flow is usually: Present item Express my opinion

  79. Tobias

    how does it and file transfer thumbnails work together?

  80. Tobias

    isn't that metadata too?

  81. Kev

    It occurs to me that this could potentially be considered leading the discussion the way the Chair wants it.

  82. MattJ

    Kev, nope, go ahead :)

  83. Kev

    Equally, I consider you all sufficiently independent to not be put off by it ;)

  84. MattJ

    I pay more attention to linuxwolf, I agree with everything he says

  85. Kev


  86. linuxwolf

    Kev: I'll call you out if I think there's over bias (-:

  87. Kev

    Tobias: It is, yes.

  88. stpeter

    thumbnails = http://xmpp.org/extensions/xep-0264.html

  89. linuxwolf


  90. MattJ


  91. Kev

    Tobias: I don't *think* it conflicts with that - do you think it does?

  92. Kev

    Or are you suggesting they should be rolled together?

  93. Tobias

    Kev, right...the reference to the thumbnail could be included in the metadata form as a field

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

  95. stpeter

    yay, über-meta!

  96. linuxwolf

    but I'd not object to rolling everything together

  97. Kev

    So, what's the tone here? Accept it and extend it for other extensions, or reject for not being complete?

  98. Kev

    I'm on the first of these.

  99. linuxwolf

    especially considering that thumbnail is currently deferred

  100. linuxwolf


  101. linuxwolf


  102. Tobias

    Kev, pidgin transfers thumbnails via bits of binary

  103. stpeter

    linuxwolf: it was deferred mostly because we were waiting to finish the other FT specs

  104. linuxwolf

    I'd accept as is, and work in extensions by draft

  105. stpeter

    linuxwolf: wfm

  106. Tobias


  107. Kev

    Does anyone disagree with this?

  108. Tobias

    i'm all okay for accepting it as experimental

  109. MattJ

    I agree with linuxwolf

  110. Kev


  111. Kev

    4) 47 to Final

  112. Kev

    Which I think means 47 Last Call.

  113. Kev


  114. Kev


  115. MattJ


  116. linuxwolf


  117. Tobias


  118. stpeter

    those Final XEPs are so lonely, they need some more friends...

  119. MattJ


  120. Kev

    Ok. Peter gets to issue a CFE then. Lucky Peter :)

  121. linuxwolf

    let's make sure every t is dotted and i is crossed, though (-:

  122. Kev


  123. Kev

    5) 292 to Draft

  124. Kev

    I think this is premature.

  125. stpeter

    I won't issue the CFE until January

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

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

  128. Tobias

    isn't that even implemented somewhere vCard4 over XMPP?

  129. Tobias


  130. linuxwolf

    Tobias: not yet, that I'm aware of

  131. Kev

    Tobias: No, but if Peter says I misread his intention, we can move along :)

  132. MattJ

    Link Mauve has a module for Prosody, but it's experimental at the moment

  133. Tobias


  134. Kev

    5) 45 1.25.

  135. MattJ


  136. Kev

    I'd like to do this next year.

  137. linuxwolf


  138. linuxwolf

    I need to re-read it again

  139. MattJ

    I read the whole thing last night... :)

  140. stpeter

    yeah it's rather large

  141. Kev

    As I'm 'on holiday' until then, and would rather not spend my time off reading all of 45.

  142. stpeter

    MattJ: good for you :)

  143. MattJ

    last "morning" night

  144. stpeter

    Kev: fully agree!

  145. Kev

    Ok. So we're agreed to discuss it next year then, fab.

  146. Kev

    7) Date of next meeting.

  147. Kev

    January 4th, 5pm GMT?

  148. MattJ


  149. linuxwolf

    -1; other commitments

  150. Kev


  151. MattJ


  152. Tobias


  153. linuxwolf

    I can do 1/3 @ 17:00 UTC

  154. stpeter

    I'll likely be slammed on the 4th with IESG reading

  155. linuxwolf checks calendar some more

  156. MattJ

    stpeter, the IESG doesn't take a holiday for Christmas? :)

  157. stpeter

    11th is fine with me

  158. stpeter

    MattJ: we do, sort of, but we have a big telechat on the 5th

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

  160. linuxwolf

    Wednesdays and Thursdays are very meeting heavy for me

  161. Kev

    Should we be doing a different day, then?

  162. stpeter can attest to linuxwolf's meeting madness

  163. Kev

    I would rather neither Monday or Friday, but Tuesday seems generally doable for me.

  164. linuxwolf

    I was able to do 16:00 UTC … 17:00UTC is 10:00 MST, which is when everyone else schedules their meetings /-:

  165. stpeter

    Tuesday is better than Wednesday for me, at least through the end of March

  166. Kev

    linuxwolf: Ah, so it's all Tobias's fault. That makes sense.

  167. linuxwolf

    Tuesdays are better, although I'd likely miss every 3rd meeting

  168. linuxwolf


  169. Tobias

    i could do tuesdays too

  170. Kev

    Tuesday 3rd January 1700?

  171. linuxwolf


  172. Kev

    (With a plan to make this the regular slot)

  173. Tobias


  174. MattJ


  175. Kev


  176. linuxwolf


  177. Kev

    8) Any other business?

  178. MattJ

    Not here

  179. stpeter

    although the 4th would be an appropriate date for a meeting, given that Jer released jabberd on January 4, 1999 ;-)

  180. linuxwolf

    so we'll celebrate the eve of the release (-:

  181. Kev


  182. linuxwolf

    no aob from me

  183. Kev

    Ok, I tihnk we're done.

  184. Kev

    Thanks all

  185. stpeter updates the calendar

  186. Kev

    Consider yourselves gavelbanged.

  187. linuxwolf


  188. linuxwolf


  189. Tobias


  190. 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 ?

  191. Tobias

    i have the feeling not but i thought you might know more

  192. stpeter

    Tobias: I am not sure, but I can inquire

  193. stpeter

    I also want to find out if they have plans for s2s

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

  195. stpeter

    MattJ: thanks for the MUC notes

  196. MattJ


  197. stpeter

    Tobias: indeed :)

  198. stpeter

    Tobias: ok I've pinged one of my MS contacts

  199. Tobias


  200. stpeter goes back to reviewing the issues at http://trac.tools.ietf.org/wg/iri/trac/report/1 :(

  201. stpeter

    ok, that's done! :)

  202. stpeter

    IRIs are the bane of my existence

  203. MattJ

    I read "IRS" at first

  204. stpeter


  205. stpeter

    I haven't had trouble with the IRS in quite some time