XMPP Council - 2013-02-27


  1. m&m has joined

  2. m&m

    is there a council meeting tomorrow?

  3. m&m

    from the logs, it looks like there is

  4. Tobias has left

  5. m&m has left

  6. Tobias has left

  7. Tobias has joined

  8. m&m has joined

  9. m&m has left

  10. stpeter updates the calendar to reflect tomorrow's meetings

  11. stpeter

    done (board too)

  12. stpeter has left

  13. Tobias has left

  14. Tobias has joined

  15. Kev

    Sorry, I've been unwell. I think I'll be able to do Council later, but if I don't make it - apologies.

  16. Tobias

    Get well.

  17. Tobias

    if it helps your condition there are somd patches to review ^^

  18. Tobias

    bbl

  19. Tobias has left

  20. Tobias has joined

  21. Tobias has left

  22. Tobias has joined

  23. Tobias has left

  24. Tobias has joined

  25. Tobias has left

  26. m&m has joined

  27. Kev

    Ah. I guess I should have sent out an agenda.

  28. m&m

    (-:

  29. stpeter has joined

  30. Kev

    Righty.

  31. Kev

    I've poked Ralph.

  32. Tobias

    k

  33. MattJ

    Present

  34. Kev

    1) Roll call

  35. Tobias

    here

  36. Kev

    -1 to MattJ for top-posting :)

  37. ralphm has joined

  38. MattJ

    :P

  39. m&m

    haha

  40. m&m

    presente

  41. stpeter

    sort of here :-)

  42. ralphm

    Present. And what Kev said

  43. MattJ

    I was pipelining

  44. Tobias

    haha

  45. MattJ

    +1

  46. Kev

    2) Move for MattJ to buy cakes for everyone

  47. m&m

    +1

  48. ralphm

    +1

  49. Tobias

    +1

  50. Kev

    +1

  51. m&m

    don't forget international shipping costs!

  52. Kev

    :D

  53. Kev

    2b) http://xmpp.org/extensions/inbox/last-seen-online.html Accept as Experimental?

  54. Kanchil

    Kev: http://xmpp.org/extensions/inbox/last-seen-online.html: XEP-XXXX: Last Presence using Delayed Delivery

  55. Tobias

    +1, typo fixes will follow when it's in the repo

  56. m&m

    no objections

  57. Kev

    Minor issue in that it's not legal by 6121 :p

  58. Kev

    Clients can't send probes.

  59. Tobias

    who are you , the XMPP police?

  60. Tobias

    Kev, is that a MUST NOT or a SHOULD NOT?

  61. Kev

    SHOULD

  62. Tobias

    SHOULD was allowed when there one knows what one is doing, right?

  63. ralphm

    I was just looking at that indeed

  64. Kev

    "Presence probes SHOULD NOT be sent by a client, because in general a client will not need to send them since the task of gathering presence from a user's contacts is managed by the user's server. However, if a user's client generates an outbound presence probe then the user's server SHOULD route the probe (if the contact is at another server) or process the probe (if the contact is at the same server) and MUST NOT use its receipt of the presence probe from a connected client as the sole cause for returning a stanza or stream error to the client."

  65. stpeter

    arguably that would be more appropriate as an "ought not"

  66. ralphm

    process the probe is a problem

  67. ralphm

    for this protocol

  68. Kev

    ralphm: Is it?

  69. m&m

    I think this protocol is legal for the letter of 6121

  70. ralphm

    You don't want any caching or whatever here.

  71. m&m

    it might not fit the spirit

  72. ralphm

    by the server, when responding to the probe

  73. ralphm

    (if it processes it)

  74. m&m

    ralphm: if I (linuxwolf@outer-planes.net) probe my wife (wifey@outer-planes.net), why would it send a probe?

  75. m&m

    [note: one of those is not a real jid]

  76. Kev

    Because it has no sense of personal boundaries.

  77. Kev

    You didn't want a serious answer, right? :p

  78. Kev

    Anyway, I'm not opposed to pushing it to Experimental, but might need more persuading that it's good to go to Draft.

  79. m&m

    well, I kind of wanted to prove a point about users on the same server, but whatever (-:

  80. ralphm

    m&m: you might be right, never mind then

  81. ralphm

    not opposed

  82. m&m

    the server's going to cache some stuff, or it would be constantly probing connected clients

  83. ralphm

    right

  84. Kev

    MattJ: ?

  85. m&m

    personally, I'm ok with this, but an explanation of why it bends the SHOULD NOT from 6121

  86. m&m

    and maybe a discussion on performance and security ramifications

  87. Tobias

    will add a sentence or two for that

  88. ralphm

    but wait

  89. ralphm

    this is about the uptime of servers and components

  90. Kev

    Yes.

  91. Tobias

    ralphm, also

  92. ralphm

    those are not really bound by 6121 are they?

  93. Kev

    ralphm: The client is bound by not doing things that 6121 tells it not to.

  94. ralphm

    hm yeah

  95. Kev

    I think MattJ's wandered off, so...

  96. Kev

    3) http://xmpp.org/extensions/inbox/last-user-in-presence.html

  97. Kanchil

    Kev: http://xmpp.org/extensions/inbox/last-user-in-presence.html: XEP-XXXX: Last User Interaction in Presence

  98. m&m

    I still say run it up the flag pole and see who salutes

  99. ralphm

    I guess we wanted to discourage to avoid presence probe storms

  100. Kev

    m&m: Yes, I agree.

  101. stpeter

    in 6121bis I'll change that to "there's really no reason for the client to send probes, because the server does that on its behalf" :P

  102. Kev

    OK.

  103. Kev

    I'm +1 on (3).

  104. ralphm

    Not opposed

  105. MattJ

    I'm +1 on (2) and (3)

  106. m&m

    other than the illegal protocol, I've no objections

  107. Tobias

    +1

  108. Tobias

    m&m, illegal protocol?

  109. Kev

    show>available?

  110. m&m

    ("available" is not one of the enumerated show values)

  111. Tobias

    yeah..typos

  112. Tobias

    will fix those

  113. ralphm

    hehe

  114. m&m

    (-:

  115. Tobias

    i falsely expected the IETF to publish consistent documents ^^

  116. m&m

    next thing you know, he's introduce <presence type='available'/>, or even <presence type='invisible'/> (-:

  117. m&m

    Tobias: pffth

  118. ralphm

    <priority>-128</priority>

  119. Kev

    I think that's all of us.

  120. m&m

    <priority>65356</priority>

  121. Kev

    I've got a 0.2 of 308 waiting for our esteemed Editor to publish :)

  122. stpeter

    oh yeah

  123. m&m

    yay!

  124. stpeter

    I saw that

  125. stpeter processes

  126. Kev

    I don't really think the LC feedback was substantive enough to justify a second LC for that.

  127. Kev

    4) Do we need another LC for 308?

  128. Kev

    I think it was pretty much a tightening of language and adding detail so it's not worth it.

  129. Kev

    But we can issue another LC if people want.

  130. MattJ

    Is there a diff somewhere?

  131. m&m

    I think you're right, but I'd like to see the diff first

  132. Tobias

    MattJ, the diff tool should be working again

  133. Kev

    http://gitorious.org/xmpp/xmpp/commit/3a09ba0ef53087de391985bd9439b8df60840a25/diffs/e68bc9404d260908b9f9c9060f5a4413cbdf9b7f

  134. Kanchil

    Kev: http://gitorious.org/xmpp/xmpp/commit/3a09ba0ef53087de391985bd9439b8df60840a25/diffs/e68bc9404d260908b9f9c9060f5a4413cbdf9b7f: Gitorious

  135. ralphm

    Kanchil: so helpful

  136. Kev

    Yeah. Sometimes that feature's handy. Other times, not so much.

  137. ralphm

    I like the namespace registration bit change, THIS PROTOXEP

  138. Kev

    So, shall we issue another LC, or vote on moving this to draft next meeting?

  139. m&m

    I need time to read it

  140. MattJ

    LGTM

  141. MattJ

    I'm fine with delaying, no need to rush it now

  142. Kev

    m&m: I'm not asking you to vote now, only if we should plan to LC it or plan to vote on it for next meeting.

  143. Kev

    But we can delay that too if you want.

  144. m&m

    I understand that, but I kind of wanted to peruse it before deciding (-:

  145. Kev

    Tell you what - I'll shove a vote on Draft to the next agenda unless you get in touch to say we need another LC instead.

  146. m&m

    we could just declare the vote starts meeting, and I could −1 if I really object

  147. m&m

    wfm

  148. Kev

    OK.

  149. Kev

    5) Date of next.

  150. Kev

    Next week?

  151. ralphm

    +1

  152. Kev

    IETF is the one after, right?

  153. m&m

    I'm not available

  154. m&m

    IETF is the week after, I was taking a short holiday immediately preceding

  155. Kev

    OK. So three weeks, then?

  156. Tobias

    next week wfm

  157. Kev

    Tobias: Do keep up, 007.

  158. ralphm

    I am good for any week for the forseeable future

  159. Tobias

    Kev, will do

  160. Kev

    Let's do three weeks today, then, when Matt and Peter will be recovered from the IETF :)

  161. stpeter

    wfm

  162. Tobias

    k

  163. m&m

    heh, "recovered"

  164. m&m

    wfm

  165. ralphm

    i.e. until I have found a new gig

  166. Kev

    m&m: Repossessed? :p

  167. ralphm

    heh, I'm sure IETF does need recovery time

  168. stpeter checks http://xmpp.org/extensions/diff/api/xep/0308/diff/0.1/vs/0.2

  169. Kev

    6) AOB?

  170. Tobias

    stpeter, don't do that

  171. Tobias

    here: what about deprecating XEP-0012? any requirements for this? should any of the new XEPs have a note about it or so?

  172. Tobias

    stpeter, seems to work now..strange...didn't work a minute agao

  173. stpeter

    Tobias: so I noticed

  174. Kev

    Tobias: I don't think we do anything about it until the new ones are more mature.

  175. stpeter nods to Kev

  176. Tobias

    Kev, oki dokey

  177. m&m

    exactly

  178. Kev

    Although you can add notes saying "Intend to ..." to the new ones if you want.

  179. m&m

    the others need to get to draft first, I think

  180. Tobias

    m&m, ah..good to know

  181. stpeter

    Kev: XEP-0308 updated

  182. m&m

    w00t

  183. stpeter

    brb

  184. Kev

    stpeter: Ta muchly.

  185. Kev

    No AOB?

  186. m&m

    none from me

  187. m&m

    and stpeter wandered away irl

  188. Tobias

    mine was just answered

  189. Kev

    Longest Council meeting for ages, nearly the full 30 mins!

  190. Kev

    Right, we're done.

  191. Tobias

    28 on my clock

  192. Kev

    Thanks all :)

  193. Kev bangs the gavel

  194. Tobias

    yay

  195. Tobias

    thank you

  196. Kev returns to convalescing :)

  197. Tobias picks up a dict

  198. stpeter

    so March 20 for the next meeting, right?

  199. Kev

    Sounds about right.

  200. Kev goes to check

  201. Kev

    Yes, March 20th.

  202. stpeter

    calendar updated

  203. ralphm

    yay

  204. ralphm

    the start of spring

  205. stpeter

    North America will be on Daylight Saving Time by then, I think

  206. ralphm

    yes

  207. ralphm

    and europe not

  208. stpeter

    so we yanks will try not to get confused

  209. Kev

    31st March the Council times will change :D

  210. Tobias

    UTC FTW :)

  211. Kev

    (Which is when GB changes)

  212. Tobias

    don't know when DE changes, but my clock will probably tell me

  213. ralphm

    all of europe changes at the same time

  214. Tobias

    ralphm, really? didn't know that

  215. stpeter

    it's be awfully confusing otherwise

  216. Tobias

    stpeter, that hasn't stopped civilisation from doing so anyway

  217. ralphm

    Tobias: yes. In fact where the UK changes at 01:00, CET changes at 02:00 and so on

  218. Tobias has left

  219. m&m has left

  220. m&m has joined

  221. Tobias has joined

  222. m&m has left

  223. m&m has joined

  224. Dave Cridland has joined

  225. Dave Cridland has left

  226. m&m has left

  227. m&m has joined

  228. bear has left

  229. bear has joined

  230. stpeter has left

  231. m&m has left

  232. Tobias has left

  233. Tobias has joined