XMPP Council - 2013-02-27

  1. m&m

    is there a council meeting tomorrow?

  2. m&m

    from the logs, it looks like there is

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

  4. stpeter

    done (board too)

  5. Kev

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

  6. Tobias

    Get well.

  7. Tobias

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

  8. Tobias


  9. Kev

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

  10. m&m


  11. Kev


  12. Kev

    I've poked Ralph.

  13. Tobias


  14. MattJ


  15. Kev

    1) Roll call

  16. Tobias


  17. Kev

    -1 to MattJ for top-posting :)

  18. MattJ


  19. m&m


  20. m&m


  21. stpeter

    sort of here :-)

  22. ralphm

    Present. And what Kev said

  23. MattJ

    I was pipelining

  24. Tobias


  25. MattJ


  26. Kev

    2) Move for MattJ to buy cakes for everyone

  27. m&m


  28. ralphm


  29. Tobias


  30. Kev


  31. m&m

    don't forget international shipping costs!

  32. Kev


  33. Kev

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

  34. Kanchil

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

  35. Tobias

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

  36. m&m

    no objections

  37. Kev

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

  38. Kev

    Clients can't send probes.

  39. Tobias

    who are you , the XMPP police?

  40. Tobias

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

  41. Kev


  42. Tobias

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

  43. ralphm

    I was just looking at that indeed

  44. 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."

  45. stpeter

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

  46. ralphm

    process the probe is a problem

  47. ralphm

    for this protocol

  48. Kev

    ralphm: Is it?

  49. m&m

    I think this protocol is legal for the letter of 6121

  50. ralphm

    You don't want any caching or whatever here.

  51. m&m

    it might not fit the spirit

  52. ralphm

    by the server, when responding to the probe

  53. ralphm

    (if it processes it)

  54. m&m

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

  55. m&m

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

  56. Kev

    Because it has no sense of personal boundaries.

  57. Kev

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

  58. Kev

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

  59. m&m

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

  60. ralphm

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

  61. ralphm

    not opposed

  62. m&m

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

  63. ralphm


  64. Kev

    MattJ: ?

  65. m&m

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

  66. m&m

    and maybe a discussion on performance and security ramifications

  67. Tobias

    will add a sentence or two for that

  68. ralphm

    but wait

  69. ralphm

    this is about the uptime of servers and components

  70. Kev


  71. Tobias

    ralphm, also

  72. ralphm

    those are not really bound by 6121 are they?

  73. Kev

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

  74. ralphm

    hm yeah

  75. Kev

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

  76. Kev

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

  77. Kanchil

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

  78. m&m

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

  79. ralphm

    I guess we wanted to discourage to avoid presence probe storms

  80. Kev

    m&m: Yes, I agree.

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

  82. Kev


  83. Kev

    I'm +1 on (3).

  84. ralphm

    Not opposed

  85. MattJ

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

  86. m&m

    other than the illegal protocol, I've no objections

  87. Tobias


  88. Tobias

    m&m, illegal protocol?

  89. Kev


  90. m&m

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

  91. Tobias


  92. Tobias

    will fix those

  93. ralphm


  94. m&m


  95. Tobias

    i falsely expected the IETF to publish consistent documents ^^

  96. m&m

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

  97. m&m

    Tobias: pffth

  98. ralphm


  99. Kev

    I think that's all of us.

  100. m&m


  101. Kev

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

  102. stpeter

    oh yeah

  103. m&m


  104. stpeter

    I saw that

  105. stpeter processes

  106. Kev

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

  107. Kev

    4) Do we need another LC for 308?

  108. Kev

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

  109. Kev

    But we can issue another LC if people want.

  110. MattJ

    Is there a diff somewhere?

  111. m&m

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

  112. Tobias

    MattJ, the diff tool should be working again

  113. Kev


  114. Kanchil

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

  115. ralphm

    Kanchil: so helpful

  116. Kev

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

  117. ralphm

    I like the namespace registration bit change, THIS PROTOXEP

  118. Kev

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

  119. m&m

    I need time to read it

  120. MattJ


  121. MattJ

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

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

  123. Kev

    But we can delay that too if you want.

  124. m&m

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

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

  126. m&m

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

  127. m&m


  128. Kev


  129. Kev

    5) Date of next.

  130. Kev

    Next week?

  131. ralphm


  132. Kev

    IETF is the one after, right?

  133. m&m

    I'm not available

  134. m&m

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

  135. Kev

    OK. So three weeks, then?

  136. Tobias

    next week wfm

  137. Kev

    Tobias: Do keep up, 007.

  138. ralphm

    I am good for any week for the forseeable future

  139. Tobias

    Kev, will do

  140. Kev

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

  141. stpeter


  142. Tobias


  143. m&m

    heh, "recovered"

  144. m&m


  145. ralphm

    i.e. until I have found a new gig

  146. Kev

    m&m: Repossessed? :p

  147. ralphm

    heh, I'm sure IETF does need recovery time

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

  149. Kev

    6) AOB?

  150. Tobias

    stpeter, don't do that

  151. Tobias

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

  152. Tobias

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

  153. stpeter

    Tobias: so I noticed

  154. Kev

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

  155. stpeter nods to Kev

  156. Tobias

    Kev, oki dokey

  157. m&m


  158. Kev

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

  159. m&m

    the others need to get to draft first, I think

  160. Tobias

    m&m, ah..good to know

  161. stpeter

    Kev: XEP-0308 updated

  162. m&m


  163. stpeter


  164. Kev

    stpeter: Ta muchly.

  165. Kev

    No AOB?

  166. m&m

    none from me

  167. m&m

    and stpeter wandered away irl

  168. Tobias

    mine was just answered

  169. Kev

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

  170. Kev

    Right, we're done.

  171. Tobias

    28 on my clock

  172. Kev

    Thanks all :)

  173. Kev bangs the gavel

  174. Tobias


  175. Tobias

    thank you

  176. Kev returns to convalescing :)

  177. Tobias picks up a dict

  178. stpeter

    so March 20 for the next meeting, right?

  179. Kev

    Sounds about right.

  180. Kev goes to check

  181. Kev

    Yes, March 20th.

  182. stpeter

    calendar updated

  183. ralphm


  184. ralphm

    the start of spring

  185. stpeter

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

  186. ralphm


  187. ralphm

    and europe not

  188. stpeter

    so we yanks will try not to get confused

  189. Kev

    31st March the Council times will change :D

  190. Tobias

    UTC FTW :)

  191. Kev

    (Which is when GB changes)

  192. Tobias

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

  193. ralphm

    all of europe changes at the same time

  194. Tobias

    ralphm, really? didn't know that

  195. stpeter

    it's be awfully confusing otherwise

  196. Tobias

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

  197. ralphm

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