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


  23. m&m

    or am I an hour early?

  24. MattJ


  25. MattJ


  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


  38. MattJ


  39. Kev


  40. Tobias


  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


  44. MattJ

    Me too

  45. Tobias


  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


  64. stpeter

    that's it from me

  65. Kev

    I've noted adding 288 and 152 to next Council.

  66. stpeter


  67. Kev

    I think we're done then.

  68. Kev

    Thanks all

  69. Kev bangs the gavel.

  70. m&m


  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


  75. MattJ

    I guess we need something to keep our mailing lists active

  76. m&m


  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


  80. m&m


  81. m&m


  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


  91. MattJ

    Thought so. It's all the C++ you've been doing :)

  92. m&m


  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


  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


  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


  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