XMPP Council - 2013-04-10


  1. Neustradamus has left
  2. Tobias has left
  3. Tobias has joined
  4. Tobias has left
  5. Neustradamus has left
  6. Neustradamus has left
  7. m&m has left
  8. Tobias has left
  9. Tobias has joined
  10. Kev has joined
  11. jabberjocke has joined
  12. Tobias has left
  13. Tobias has joined
  14. Tobias has left
  15. Tobias has joined
  16. jabberjocke has left
  17. Tobias has left
  18. Tobias has joined
  19. m&m has joined
  20. jabberjocke has joined
  21. MattJ has joined
  22. m&m ding?
  23. m&m or am I an hour early?
  24. MattJ Dong
  25. MattJ Nope
  26. MattJ Kev is... *gasp* late
  27. MattJ By 32 seconds
  28. Kev It is time.
  29. m&m dislikes Daylight Savings Time
  30. MattJ too
  31. Kev I've poked Ralph.
  32. Kev Did I miss anything, or is there nothing to discuss this week?
  33. stpeter has joined
  34. Kev 1) Roll call.
  35. Kev I'm here.
  36. m&m presente (for once)
  37. stpeter howdy
  38. MattJ Here
  39. Kev Tobias:?
  40. Tobias here
  41. Kev Assuming I didn't miss anything and there's nothing for this week again...
  42. Kev 3) Date of next meeting.
  43. m&m SBTSBC WFM
  44. MattJ Me too
  45. Tobias wfm
  46. Kev And for me.
  47. stpeter I still need to publish a few things from the inbox
  48. Kev But that's for next week?
  49. Kev 4) AOB?
  50. stpeter no, just noting my action items :-)
  51. m&m none from me
  52. stpeter however, the last call for XEP-0152 finished
  53. stpeter so I suppose the Council can vote on it at some point
  54. Kev Did we have a sum total of no feedback on that one, or do I misremember?
  55. stpeter same for 288
  56. stpeter there was pre-LC feedback on 152
  57. stpeter from Lance, at least, IIRC
  58. Kev Fippo's comment on 288 suggested that there were (probably minor) changes still to come on that.
  59. stpeter and feedback from Zash on 288
  60. Kev I've poked Fippo to see if 288 changes are coming.
  61. stpeter I will review 288 this week
  62. Kev I'll try to dig out the feedback on 152, I didn't notice it.
  63. stpeter nod
  64. stpeter that's it from me
  65. Kev I've noted adding 288 and 152 to next Council.
  66. stpeter thanks!
  67. Kev I think we're done then.
  68. Kev Thanks all
  69. Kev bangs the gavel.
  70. m&m grazie
  71. stpeter notes to himself that he needs to issue a Last Call on XEP-0220, too
  72. MattJ Do you have to?
  73. MattJ Can't we just, you know... leave it as it is? :P
  74. stpeter :P
  75. MattJ I guess we need something to keep our mailing lists active
  76. m&m heh
  77. stpeter hey, it has been in use since ~October 2000 and was in a Proposed Standard RFC, I think it deserves to be something other than an Experimental XEP :P
  78. m&m you could always propose an alternative (-:
  79. Kev 'backdial
  80. m&m fwdcall?
  81. m&m er…callfwd
  82. stpeter tunes out the banter and pays attention to his conference call :P
  83. Tobias so..AOB section done?
  84. Kev Meeting done.
  85. Kev 7 minutes ago.
  86. MattJ wb Tobias :)
  87. Tobias ahh..overread that line
  88. Tobias MattJ, been there all the time...physically
  89. MattJ But mentally...?
  90. Tobias menta...what?
  91. MattJ Thought so. It's all the C++ you've been doing :)
  92. m&m ouch
  93. Tobias or the couple minutes lua i squeezed in a week ago
  94. fippo has joined
  95. fippo hah, the dialback alternative will of course be turbohalibut!
  96. fippo don't you read xmpp@ietf.org? ;-)
  97. m&m fippo: uhm … no
  98. m&m POSH actually is turbohalibut
  99. m&m are you sure *you* read xmpp@ietf.org? (-:
  100. MattJ Haha
  101. m&m hands fippo compress for the burn
  102. fippo goes digging the archives
  103. fippo well, POSH doesn't DER-encode, does it?
  104. fippo i'm pretty sure this step is crucial for turbohalibut
  105. m&m has left
  106. m&m has joined
  107. m&m has left
  108. m&m has joined
  109. fippo has left
  110. Tobias has left
  111. jabberjocke has left
  112. Kev User exists but hasn't yet implicitly created a roster by adding anything to it. Does the roster exist or not?
  113. Kev i.e. does the text saying that you MUST NOT return an error, or the text saying you MUST return an error apply?
  114. Kev ( http://tools.ietf.org/html/rfc6121#section-2.1.4 )
  115. Kanchil Kev: http://tools.ietf.org/html/rfc6121#section-2.1.4: RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
  116. Tobias has joined
  117. MattJ Kev, in Prosody no stored data == empty stored data
  118. MattJ so we treat it as an empty roster
  119. Kev Ta.
  120. Kev Anyone else?
  121. Tobias has joined
  122. Neustradamus has left
  123. m&m has left
  124. m&m has joined
  125. m&m Cisco products behave similarly
  126. Kev Merci.
  127. m&m for roster
  128. MattJ btw, we also actually load the roster when the user binds their resource
  129. MattJ and fail binding if it can't be loaded
  130. m&m has left
  131. MattJ (failure, as opposed to not existing)
  132. MattJ This was so we don't end up overwriting it, or confusing clients into thinking they have an empty or no roster
  133. Kev Yes, that's quite sensible.
  134. m&m has joined
  135. m&m has left
  136. m&m has joined
  137. jabberjocke has joined
  138. m&m has left
  139. m&m has joined
  140. m&m has left
  141. m&m has joined
  142. stpeter has left
  143. m&m has left