XMPP Council - 2012-11-21

  1. Kev

    T-2 hours.

  2. m&m

    am I early or late?

  3. Kev


  4. Kev

    32 minutes.

  5. m&m


  6. m&m

    holiday + timezone differences == confusion

  7. Kev

    Honoured you're taking time out of the holiday to chat to us... :)

  8. m&m

    well, I suppose we should have a first meeting at some point before 2013 (-:

  9. Kev

    It does seem desirable.

  10. Kev

    I've poked Ralph, but he's got another minute anyway :)

  11. Kev

    Ah, and at that moment his client auto-idles :)

  12. Kev

    I did check with him last night that he'd be here, so shall we give him a few minutes?

  13. m&m


  14. Kev

    I'm fairly keen that for electing a chair everyone's here, even if for no other votes of the year :)

  15. m&m


  16. Tobias


  17. Kev

    Excellent. Just Ralph, then.

  18. Kev drums his fingers on the desk.

  19. m&m


  20. MattJ

    I'm in no hurry, FWIW :)

  21. Tobias

    so for this kev had to wake me up ^^

  22. Kev

    MattJ: m&m's on holiday, it'd be nice to not keep him indefinitely :)

  23. m&m


  24. MattJ

    I didn't say m&m wasn't in a hurry

  25. Kev

    Obviously the rest of you I don't care about :D

  26. m&m


  27. Kev

    Board had to vote on a Chair yesterday with just 3/5 present.

  28. Kev

    So we'll beat that with 4/5 even if Ralph doesn't appear :)

  29. Kev

    I'd suggest if we wait until 15past and then go ahead regardless it'd seem fair - what do others think?

  30. m&m

    at least it's quorum

  31. m&m

    that works for me

  32. m&m

    I'm not in a hurry

  33. MattJ


  34. MattJ

    I'm +1 to :15

  35. MattJ

    Ok, for want of something to discuss, and while we're all here...

  36. MattJ

    *mostly all here

  37. Kev

    I'm mostly all there.

  38. MattJ


  39. Kanchil

    MattJ: http://matthewwild.co.uk/uploads/xep-json.html: XEP-xxxx: JSON container

  40. MattJ

    Shush Kanchil

  41. m&m


  42. MattJ


  43. Kev

    It's quarter past.

  44. m&m

    let's just do this

  45. Kev

    I guess we should go ahead, if we want to be sure of finishing on time.

  46. Kev

    1) Roll call.

  47. Kev

    I'm here.

  48. m&m


  49. MattJ


  50. Kev

    Tobias was here 7 minutes ago. I hope he's still here now :)

  51. Kev

    I guess we'll find out if he's not when we do (2) :)

  52. Kev

    2) Electing chair.

  53. Tobias


  54. Tobias


  55. Kev

    I'm happy to do it. Would anyone else like to be considered?

  56. MattJ


  57. m&m

    I'm fine playing backup (-:

  58. Zash whispers "Elect Ralph in his absence"

  59. Tobias

    yeah..let's all vote on backup :P

  60. MattJ


  61. m&m


  62. Kev


  63. Kev

    Should I take that as "no-one else standing", then?

  64. m&m


  65. Kev

    In which case: Vote for Kev to be chair...

  66. MattJ


  67. m&m

    +1 to Kev

  68. Tobias


  69. Kev


  70. MattJ


  71. Kev


  72. Kev

    Without even resorting to threats of physical violence.

  73. Tobias


  74. Kev

    3) Message Forwarding. Last Call?

  75. MattJ


  76. m&m


  77. Kev

    That's "Stanza Forwarding', actually, isn't it?

  78. MattJ

    It is

  79. Kev

    297, in any case.

  80. m&m


  81. Kev

    I'm +1 on an LC.

  82. Tobias

    can you also forward IQs?

  83. Kev

    Tobias: If you want to.

  84. MattJ


  85. Tobias

    then +1

  86. MattJ

    I won't pretend that's useful though

  87. m&m

    there's limited applicability for IQs

  88. Kev

    I can only come up with contrived examples, at first glance.

  89. m&m

    such as end-to-end encryptkon

  90. m&m


  91. m&m

    which I need to add to the draft

  92. Kev

    I'm +1 too.

  93. Kev

    4) Date of next meeting

  94. MattJ

    I'm starting to feel obligated to anticipate all the horrible ways people might use XEPs I write and include "Please don't do this" requests

  95. Kev

    Next Wednesday, 1600UTC?

  96. m&m

    Kev: +1

  97. MattJ


  98. Tobias


  99. m&m

    MattJ: the only solution is to not write XEPs (-:

  100. Kev

    Marvellous. Board have timed their meetings to be weekly, immediately subsequent to Council this year, which is convenient if anyone wants to drop in and heckle.

  101. MattJ

    Easier said than done

  102. Kev

    Oh, no, it's quite easy.

  103. MattJ

    Kev, yes, that's a great idea

  104. Kev

    You just join the MUC and make irrelevant comments.

  105. MattJ

    They're still in xsf@?

  106. Kev

    ...oh, you didn't mean that :D

  107. Kev


  108. m&m


  109. Kev

    5) Any other business

  110. Kev

    I'll do my now traditional "Anything anyone wants to change about the way Council is chaired/run this year?" question.

  111. m&m


  112. Zash

  113. MattJ

    It's been pretty ok with me, except when meeting times change, or when I think they have, but they haven't really

  114. Kev

    I've now, I hope, passed the ludicrously busy spell I had the last couple of months. I've not had to go on site for multiple weeks in a row \o/.

  115. m&m


  116. Kev


  117. Kev

    Any other any other business?

  118. MattJ

    Not here

  119. m&m


  120. Tobias


  121. m&m ignores that jay-son thingie

  122. Kev

    Marvellous. Despite a delayed start, 4 minutes to spare.

  123. Kev bangs the gavel.

  124. MattJ

    Any informal comments on the jay-son thingie? I fully intend to submit it otherwise :)

  125. Kev

    Thanks all :)

  126. MattJ

    Thanks Kev

  127. Kev

    MattJ: I think it's a bit nasty, and likely to cause pain, but it's something there's a (perceived) requirement for, so who am I to judge?

  128. MattJ

    What pain might it cause? and what (if anything) can be done to prevent it?

  129. m&m

    MattJ: to be frank, I almost no benefit to it … you still need context

  130. MattJ

    I can't be the only person who thinks JSON in <body/> is evil

  131. m&m

    I think that's evil also, but I also don't see a point to a single wrapper for all cases of JSON

  132. m&m

    guidelines for how one mixes in JSON to XMPP, sure

  133. m&m

    a single container … no

  134. Kev

    MattJ: I don't think that specification for including JSON causes pain, particularly. More that mixing content types like that doesn't seem to buy very much, and JSON isn't all that great for things that need interop and extensibility etc., and ...

  135. Kev

    m&m: This is true, but at least for the way Swift does parsing/serialising, having all json always in the same wrapper element (which is then within a context element) would be convenient.

  136. Kev


  137. Kev

    So I'm not particularly opposed to saying "If your protocol is shipping JSON, shove it inside <this> element, within your own namespaced element.

  138. Kev

    As example 2 does in MattJ's spec.

  139. MattJ


  140. Zash

    Compare to 297 and xhtml-im

  141. MattJ

    That's pretty much exactly what it's intended for

  142. m&m

    frankly, I'd only be ok if it always had to be wrapped by something else

  143. Kev

    MattJ: So I think maybe example 1 should go.

  144. Kev ^5s m&m

  145. MattJ

    I'm ok with that

  146. m&m

    in fact, I'm not sure 297 should be present without somehting wrapping it

  147. m&m

    something even

  148. Kev

    m&m: 297 does have a use case for this, which is that sometimes you really do just want to forward a message as a real forward.

  149. MattJ

    But many closed "XMPP as middleware" do already do the JSON-in-body hack, I've seen it in multiple places now, and I wince every time

  150. MattJ

    The "context" there is the sender and recipient

  151. m&m

    MattJ: I'm not saying it won't happen

  152. MattJ

    I agree that's not pretty, but it's reality

  153. Kev

    MattJ: Where interop isn't required, I don't really much care what people do :)

  154. MattJ

    I do, or they might as well not be using XMPP :)

  155. Kev

    You can encode stuff in a message body for all I care as long as it doesn't reach anyone else's system :)

  156. MattJ

    and I see this as a step up from what they do now

  157. MattJ

    I've had to interface with such systems :(

  158. Kev

    As soon as you need to interface with them, interop's required.

  159. Kev

    And it starts being clearly wrong :)

  160. MattJ

    So, happy with a "SHOULD" be inside another element?

  161. MattJ

    I think that sounds good to me

  162. m&m

    I'm happy with a MUST

  163. MattJ


  164. Kev

    TBH, I don't see much of an argument to not say MUST, although hills, etc.

  165. Kev

    In as much as anyone who's going to ignore it is going to ignore the XEP completely.

  166. MattJ


  167. m&m plants flag, burns bridge that lets me down

  168. MattJ

    But they can be coaxed in the right direction

  169. Kev

    They're not going to say "Oh, well, I'm happy to put it in this wrapper element, but my own namespace? That's just a bridge too far, melad"

  170. MattJ

    That's mostly the intention

  171. Kev

    They'll either swallow it and do the right thing, or ignore everything the spec says completely :)

  172. Kev

    So you may as well say MUST do the right thing.

  173. MattJ

    !xep 297

  174. Kanchil

    MattJ: XEP-0297(forwarding): http://xmpp.org/extensions/xep-0297.html Stanza Forwarding - Standards Track/Experimental - Updated: 2012-07-05

  175. Kev

    Ah, are we talking about 297 or JSON now?

  176. Kev

    I was talking about JSON.

  177. MattJ


  178. m&m

    I thought we were talking about JSON

  179. MattJ

    I'm just cross-referencing language :)

  180. Kev


  181. Zash

    !xep 231

  182. Kanchil

    Zash: XEP-0231(bob): http://xmpp.org/extensions/xep-0231.html Bits of Binary - Standards Track/Draft - Updated: 2008-09-03