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


  13. stpeter

    now to start rounding up Council members :P

  14. stpeter


  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


  39. MattJ

    Is Realtime Text the first XEP with an external homepage?

  40. Kev


  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


  61. stpeter

    we'll just have a friendly chat

  62. Kev

    I'll send out minutes afterwards :)

  63. stpeter


  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


  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


  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


  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


  97. stpeter

    so discovery might be good

  98. stpeter


  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


  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


  107. Kev


  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


  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


  128. Kev

    Isn't that what we have now?

  129. Kev


  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


  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


  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


  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


  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


  182. Kev


  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


  189. stpeter updates the calendar

  190. Kev


  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


  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


  207. tuomas has left

  208. stpeter

    and hashes 0.0.2 checked into git :)

  209. Kev


  210. stpeter


  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


  214. linuxwolf has left

  215. Florob has left

  216. MisterKanister has left

  217. MattJ has left

  218. stpeter has left