XMPP Council - 2013-04-10

  1. m&m

    ding?

  2. m&m

    or am I an hour early?

  3. MattJ

    Dong

  4. MattJ

    Nope

  5. MattJ

    Kev is... *gasp* late

  6. MattJ

    By 32 seconds

  7. Kev

    It is time.

  8. m&m dislikes Daylight Savings Time

  9. MattJ too

  10. Kev

    I've poked Ralph.

  11. Kev

    Did I miss anything, or is there nothing to discuss this week?

  12. Kev

    1) Roll call.

  13. Kev

    I'm here.

  14. m&m

    presente (for once)

  15. stpeter

    howdy

  16. MattJ

    Here

  17. Kev

    Tobias:?

  18. Tobias

    here

  19. Kev

    Assuming I didn't miss anything and there's nothing for this week again...

  20. Kev

    3) Date of next meeting.

  21. m&m

    SBTSBC WFM

  22. MattJ

    Me too

  23. Tobias

    wfm

  24. Kev

    And for me.

  25. stpeter

    I still need to publish a few things from the inbox

  26. Kev

    But that's for next week?

  27. Kev

    4) AOB?

  28. stpeter

    no, just noting my action items :-)

  29. m&m

    none from me

  30. stpeter

    however, the last call for XEP-0152 finished

  31. stpeter

    so I suppose the Council can vote on it at some point

  32. Kev

    Did we have a sum total of no feedback on that one, or do I misremember?

  33. stpeter

    same for 288

  34. stpeter

    there was pre-LC feedback on 152

  35. stpeter

    from Lance, at least, IIRC

  36. Kev

    Fippo's comment on 288 suggested that there were (probably minor) changes still to come on that.

  37. stpeter

    and feedback from Zash on 288

  38. Kev

    I've poked Fippo to see if 288 changes are coming.

  39. stpeter

    I will review 288 this week

  40. Kev

    I'll try to dig out the feedback on 152, I didn't notice it.

  41. stpeter

    nod

  42. stpeter

    that's it from me

  43. Kev

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

  44. stpeter

    thanks!

  45. Kev

    I think we're done then.

  46. Kev

    Thanks all

  47. Kev bangs the gavel.

  48. m&m

    grazie

  49. stpeter notes to himself that he needs to issue a Last Call on XEP-0220, too

  50. MattJ

    Do you have to?

  51. MattJ

    Can't we just, you know... leave it as it is? :P

  52. stpeter

    :P

  53. MattJ

    I guess we need something to keep our mailing lists active

  54. m&m

    heh

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

  56. m&m

    you could always propose an alternative (-:

  57. Kev

    'backdial

  58. m&m

    fwdcall?

  59. m&m

    er…callfwd

  60. stpeter tunes out the banter and pays attention to his conference call :P

  61. Tobias

    so..AOB section done?

  62. Kev

    Meeting done.

  63. Kev

    7 minutes ago.

  64. MattJ

    wb Tobias :)

  65. Tobias

    ahh..overread that line

  66. Tobias

    MattJ, been there all the time...physically

  67. MattJ

    But mentally...?

  68. Tobias

    menta...what?

  69. MattJ

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

  70. m&m

    ouch

  71. Tobias

    or the couple minutes lua i squeezed in a week ago

  72. fippo

    hah, the dialback alternative will of course be turbohalibut!

  73. fippo

    don't you read xmpp@ietf.org? ;-)

  74. m&m

    fippo: uhm … no

  75. m&m

    POSH actually is turbohalibut

  76. m&m

    are you sure *you* read xmpp@ietf.org? (-:

  77. MattJ

    Haha

  78. m&m hands fippo compress for the burn

  79. fippo goes digging the archives

  80. fippo

    well, POSH doesn't DER-encode, does it?

  81. fippo

    i'm pretty sure this step is crucial for turbohalibut

  82. Kev

    User exists but hasn't yet implicitly created a roster by adding anything to it. Does the roster exist or not?

  83. Kev

    i.e. does the text saying that you MUST NOT return an error, or the text saying you MUST return an error apply?

  84. Kev

    ( http://tools.ietf.org/html/rfc6121#section-2.1.4 )

  85. Kanchil

    Kev: http://tools.ietf.org/html/rfc6121#section-2.1.4: RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

  86. MattJ

    Kev, in Prosody no stored data == empty stored data

  87. MattJ

    so we treat it as an empty roster

  88. Kev

    Ta.

  89. Kev

    Anyone else?

  90. m&m

    Cisco products behave similarly

  91. Kev

    Merci.

  92. m&m

    for roster

  93. MattJ

    btw, we also actually load the roster when the user binds their resource

  94. MattJ

    and fail binding if it can't be loaded

  95. MattJ

    (failure, as opposed to not existing)

  96. MattJ

    This was so we don't end up overwriting it, or confusing clients into thinking they have an empty or no roster

  97. Kev

    Yes, that's quite sensible.