XSF logo XMPP Council - 2011-06-22


  1. linuxwolf has joined
  2. stpeter has joined
  3. Kev continues working through the reviews for later.
  4. stpeter prepares his second breakfast :)
  5. linuxwolf has left
  6. stpeter and while eating my second breakfast I pushed out a slightly revised version of XEP-0233 :)
  7. Kev I've almost finished realtimetext.
  8. stpeter I'm going to ping Alexey about reviewing it
  9. Kev The gift that keeps on giving :)
  10. stpeter ;-)
  11. Kev Aaand done. With plenty of time until Council :)
  12. stpeter yay!
  13. stpeter now to start rounding up Council members :P
  14. stpeter bbiaf
  15. linuxwolf has joined
  16. linuxwolf has left
  17. linuxwolf has joined
  18. Florob has joined
  19. MisterKanister has joined
  20. stpeter heh, my dent/tweet seems to have worked, although it remains to be seen how many Council members are online...
  21. MattJ has joined
  22. stpeter waves to MattJ
  23. MattJ Hey :)
  24. MattJ isn't feeling well today so has been offline, but he just remembered the meeting
  25. stpeter :(
  26. stpeter sorry to hear it
  27. MattJ I'm sure I'll survive
  28. petermount has joined
  29. stpeter well that's good news :)
  30. stpeter I pinged Ralph but he seems to be AFK
  31. stpeter Fritzy is offline as far as I can see
  32. stpeter it appears that our Council has been reduced to a Triumvirate...
  33. MattJ Is it contagious?
  34. stpeter :)
  35. Kev So. No sign of a quorum at the moment.
  36. stpeter linuxwolf is somewhat here but no doubt distracted in an IRL meeting
  37. Kev Right, linuxwolf sent apologies.
  38. stpeter yes
  39. MattJ Is Realtime Text the first XEP with an external homepage?
  40. Kev Probably.
  41. MattJ I'm half expecting to find it on Twitter and Facebook :)
  42. tuomas has joined
  43. stpeter gosh, maybe I need to get on this Facebook thing I've been hearing so much about
  44. MattJ Your face, in their book
  45. MattJ This RTT animation makes me dizzy, I never liked it in Wave either
  46. Kev So. I wonder what we should do about our wayward Council cousins.
  47. MiGri has joined
  48. MattJ Why don't we always just type half a sentence, if that's enough for the other person to start responding?
  49. Kev MattJ: I don't enjoy using it at all, but I'm not opposed to others doing so.
  50. stpeter Kev: well, one of them might not even be an XSF member any longer...
  51. MattJ Me neither (on both counts)
  52. stpeter agreed, on RTT
  53. Kev I thought RTT was vastly improved over v1, btw.
  54. MattJ ditto, though I haven't read it all yet
  55. stpeter I need to read it, too
  56. Kev Ok, shall we have a non-quorumed meeting?
  57. stpeter or a non-meeting?
  58. Kev So at least we can discuss stuff usefully, even if not pass votes.
  59. MattJ Fine by me :)
  60. stpeter sure
  61. stpeter we'll just have a friendly chat
  62. Kev I'll send out minutes afterwards :)
  63. stpeter heh
  64. Kev Of of the friendly chat :)
  65. MattJ We actually wait for votes from people not at the meeting anyway
  66. Florob Doesn't Jingle Nodes have a "external homepage"?
  67. stpeter Florob: yes
  68. Kev MattJ: Yes, but we can't start the vote period until a meeting happens.
  69. MattJ Florob, gah, you're right :)
  70. MattJ Maybe this is a trend
  71. Kev Right, so we can skip the Roll Call, and probably the Agenda bashing.
  72. Kev http://www.xmpp.org/extensions/inbox/hashes.html
  73. Kev I'm fine with the idea of this, and the implementation, except that section 4 (update namespaces) is wrong.
  74. stpeter Kev: how do you think we should handle the namespace versioning?
  75. Kev The namespace should only be updated if there's an incompatible schema change (or usage change).
  76. Kev Else we have the situation like:
  77. Kev md5 is MAY, SHA1 SHA2 are MUST. SHA3 comes out and the XEP then becomes the same but with SHA3 as MUST (for example).
  78. Kev Now someone who implemented it yesterday is unable to interop with someone implementing it tomorrow, even though they support several MTI hashes in common.
  79. Kev (Because the namespace has changed)
  80. stpeter right
  81. stpeter one question is: do we need a way to discover which hashes the other party supports?
  82. Kev So I think you use the hashes you support, and if the other side supports them great, otherwise you can't interop.
  83. stpeter I might agree that changing the namespace might not be the best way to perform that discovery
  84. Kev stpeter: Is the assumption that you only send one negotiated hash, or that you send those you support?
  85. stpeter Kev: it might depend on the protocol
  86. Kev I was assuming you'd send those hashes you support.
  87. Kev Maximum interop, for not a huge amount of overhead (unless we start talking about supporting hundreds of hashes).
  88. MattJ Yeah, discovery brings just a small optimisation (which may not actually be worth it in some cases)
  89. stpeter sure, but why eat of processor time to generate hashes that the other party doesn't support? (e.g., in file transfer)
  90. stpeter s/of/up/
  91. Kev (This is notable not suitable if you're doing something like password hashing, where having multiple is a vulnerability, of course).
  92. Kev stpeter: Right, in that case we probably want negotiation.
  93. Kev Well, I say negotiation.
  94. Kev I mean caps.
  95. stpeter so if I want to send you a bunch of large-ish files, I don't want to figure a checksum for SHA1, SHA2, and SHA3
  96. Kev Right.
  97. stpeter so discovery might be good
  98. stpeter but
  99. stpeter we don't need a namespace change to do that
  100. Kev So I have sha1, sha2 in my caps. You know what I support, pick the one that suits you best, use it.
  101. Kev Right.
  102. Zash has joined
  103. stpeter we could have separate disco features
  104. Kev So I think we add discovery, and remove namespace changes.
  105. stpeter that would work for me
  106. MattJ +1
  107. Kev Great.
  108. MattJ I have a small proposal, but I haven't thought it out yet
  109. linuxwolf has left
  110. linuxwolf has joined
  111. stpeter MattJ: proposal for...?
  112. MattJ This XEP
  113. MattJ Just typing :)
  114. stpeter heh ok
  115. MattJ (if only we had a way of transmitting my text as I typed...)
  116. Kev Yes, that could get hilarious in MUCs :)
  117. MattJ Instead of a <hash> element for each algorithm, what if that element contained all the algorithms?
  118. Kev 85 in MUCs would be sensible, though.
  119. Kev Maybe Swift should start doing that.
  120. MattJ Kev, it should - I'm pestering for Gajim support
  121. MattJ A number of clients are doing it now
  122. MattJ (finally)
  123. MattJ Maybe an example of my hash idea would be clearer
  124. stpeter MattJ: that might be fine, yes
  125. MattJ <hash xmlns='urn:xmpp:hashes:0'> <algo type='sha-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</algo> </hash>
  126. MattJ or something like that
  127. stpeter nod
  128. Kev Isn't that what we have now?
  129. Kev 'now'
  130. stpeter :)
  131. MattJ It's not so different really, except in the implementation you just have to iterate over the child elements of a single tag
  132. Kev Oh, I see.
  133. MattJ rather than cherry-pick all elements with the hashes namespace from amidst the rest
  134. Kev Right, that's neater if you have multiple hashes, yes.
  135. Kev Right, although your library's going to be doing that for you.
  136. MattJ Yeah, sorry, I'm lazy :)
  137. stpeter you say potayto, I say potahto
  138. MattJ Kev, depends how high-level it is, also - I write the library, so no it isn't :)
  139. stpeter nods
  140. stpeter I like that a bit better
  141. stpeter so I'll make version 0.0.2
  142. MattJ Thanks
  143. Kev Thanks Peter.
  144. Kev So, has anyone read any of http://xmpp.org/extensions/inbox/realtimetext.html ?
  145. Kev I have a longish list of issues with it, but I don't think they're sufficiently fundamental to block publication - and it's written like a XEP now, mostly, which makes life much better.
  146. MattJ Not the new version in detail, and I'm not sure I'm capable right now
  147. stpeter I haven't done so
  148. MattJ It didn't make me go "aargh" like the first one did though
  149. Kev :)
  150. stpeter heh
  151. MattJ If you're happy with publication then I probably am too, but I'll take time this week to review it and put my thoughts on-list (assuming we won't vote until next meeting?)
  152. linuxwolf has left
  153. linuxwolf has joined
  154. stpeter I'll do the same
  155. linuxwolf has left
  156. Kev We can't vote until next meeting, indeed.
  157. Kev I'll post my thoughts to the list in advance.
  158. stpeter excellent
  159. stpeter any other non-business for discussion in this non-meeting? ;-)
  160. stpeter I just updated XEP-0233
  161. stpeter and I poke some SASL people about reviewing it
  162. stpeter poked, that is
  163. Kev Not according to the agenda.
  164. Kev Unless someone else has something.
  165. stpeter so I might request a Last Call about that one before long
  166. MattJ iirc I read an email where stpeter said we could discuss something at the meeting
  167. MattJ tries to find it
  168. stpeter yes
  169. stpeter file transfer
  170. stpeter if we plug this hashes stuff into XEP-0234, then 260 and 261 are left waiting
  171. MattJ Ah, ok
  172. stpeter so I wonder if it makes sense to take care of those first
  173. stpeter we said we'd bundle them with 234
  174. bear has left
  175. stpeter but they're basically done, I think
  176. bear has joined
  177. stpeter something to discuss next time, I suppose
  178. stpeter shall we schedule the next meeting?
  179. Kev Next Wednesday, presumably.
  180. MattJ Fine with me
  181. stpeter WFM
  182. Kev Righty.
  183. stpeter updates the hashes spec and adds Matthew and Kev as authors
  184. Kev Aww shucks.
  185. Kev (And thanks)
  186. stpeter :)
  187. Kev Righty, I guess we're done with the non-meeting, then.
  188. stpeter yep
  189. stpeter updates the calendar
  190. Kev Thanks.
  191. Kev And thanks both for turning up!
  192. stpeter we're here for you!
  193. MattJ Heh, thanks :)
  194. linuxwolf has joined
  195. stpeter hmm
  196. stpeter it would be handy to reference hash algorithms like this... urn:iana:hash-function-text-names:sha-256
  197. stpeter but there is no urn:iana:* namespace
  198. stpeter contacts IANA
  199. petermount has left
  200. Kev Faux-minutes sent!
  201. Zash has left
  202. MattJ :)
  203. linuxwolf has left
  204. linuxwolf has joined
  205. Kev And that's RTT notes sent out.
  206. MattJ Thanks
  207. tuomas has left
  208. stpeter and hashes 0.0.2 checked into git :)
  209. Kev Thanks.
  210. stpeter http://xmpp.org/extensions/inbox/hashes.html
  211. Kev Brief scan looks good to me.
  212. stpeter I've poked IANA about setting up a urn:iana namespace so that we don't have to manage a separate set of disco features in the urn:xmpp tree for cryptographic hashes (although I don't see any great harm in doing so)
  213. stpeter bbiab
  214. linuxwolf has left
  215. Florob has left
  216. MisterKanister has left
  217. MattJ has left
  218. stpeter has left