XMPP Council - 2012-02-29


  1. ralphm waves

  2. Kev

    Hi Ralph.

  3. Kev

    I haven't even forgotten. Yet :)

  4. ralphm

    heh

  5. ralphm

    I was in a Zoo last week, so I did.

  6. stpeter notes that he neglected to run calgen.py until about an hour ago so the meeting might not be in your calendar

  7. linuxwolf

    oopsie

  8. ralphm

    yeah, that too (last week)

  9. Kev

    Howdy folks.

  10. Kev

    1) Bap call.

  11. Kev

    I'm here.

  12. Tobias too

  13. linuxwolf

    presente

  14. stpeter

    Matthew seems to be offline

  15. ralphm is here

  16. ralphm

    stpeter: I still don't see it

  17. Kev

    Marrrrvellous.

  18. linuxwolf

    his server seems to be gone

  19. linuxwolf

    /-:

  20. Kev

    2) http://xmpp.org/extensions/inbox/pubsub-since.html

  21. Kev

    Accept as XEP?

  22. ralphm

    +1

  23. linuxwolf

    +1

  24. ralphm

    I'd like to see an example of how it would work with RSM

  25. stpeter

    ralphm: true

  26. Kev

    I have serious reservations about this. Firstly that using a timestamp for this is broken, secondly that it says to use Last Activity In Presence, but doesn't cover what to do on non-initial presence, and thirdly that it says to use RSM but not how.

  27. MattJ

    +1... but... timestamps.

  28. Tobias

    +1

  29. stpeter

    by "timestamps" do you mean UTC?

  30. ralphm

    clock skew

  31. stpeter

    instead of last presence?

  32. stpeter

    I just used the format from iq:last

  33. Kev

    So I think all of those should be addressed in some way. That can happen on the vine, although I don't like it.

  34. MattJ

    Clock skew is my concern... giving 5 minutes' grace is fine, but then you possibly send duplicate updates

  35. Kev

    We have systems like this already, and they're proven not to work.

  36. Tobias

    Kev, what exactly has been proven not to work?

  37. Kev

    Tobias: Using time-of-last-something as a way of resynchronising history. Swift does it for MUCs, and you frequently end up with duplicate notifications.

  38. ralphm

    MattJ: true. This is only a problem with notifications that are idempotent. In some cases, they aren't, but I'm not sure if delayed delivery in those cases are proper anyway.

  39. ralphm

    /not/ idempotent

  40. Tobias

    Kev, ah..right

  41. Kev

    You don't even need clock skew for things to go wrong. You can both have duplicates and missed notifications.

  42. ralphm

    Kev: for MUCs it is a bigger problem because messages are not idempotent there

  43. Kev

    (using pubsub-since)

  44. Kev

    But anyway. It can go on the vine as everyone else is happy with this.

  45. ralphm

    well, it is not an active standard yet

  46. Kev

    I wouldn't push it to Draft in its current state, though.

  47. ralphm

    I'm not against publishing

  48. linuxwolf

    no one is asking to push it to draft yet

  49. Tobias

    right..but all this can be fixed in Experimental state

  50. Kev

    linuxwolf: No, but I'm giving a heads-up.

  51. Kev

    3) Obsoleting 130.

  52. linuxwolf

    Kev: just be sure to post to the list, too

  53. Kev

    linuxwolf: Reasonable.

  54. ralphm

    One could also argue that we are jumping through a lot of hoops to make automatic subscriptions work without the cooperation of your 'home' server. If you lose that constraint other solutions might be better.

  55. stpeter

    ralphm: as in ask your home server to do the subscription for you?

  56. MattJ

    +1 to -0130

  57. ralphm

    stpeter: in one way or the other, yes. Then it could also just receive notifications in offline storage, for example.

  58. linuxwolf

    also +1 to −0130

  59. Kev

    I'd like to do a ~Last Call on standards@ for a few weeks to say "We'll obsolete this on the Xth March unless someone says it's in use".

  60. stpeter

    Kev: for sure

  61. linuxwolf

    of course

  62. Kev

    stpeter: It wasn't clear to me how obsoleting this would affect your cleanup, though.

  63. Tobias

    Kev, sounds like a good idea

  64. MattJ

    linuxwolf, I like what you did there :)

  65. stpeter

    Kev: http://xmpp.org/extensions/xep-0172.html#waitlist

  66. Kev

    Ah, I'd completely forgotten that was there.

  67. Kev

    Fairy nerfs, then.

  68. ralphm

    what is the necessity of obsoleting this specification?

  69. stpeter

    ralphm: first, I'd like to clean up XEP-0172

  70. stpeter

    ralphm: second, no one is using it

  71. stpeter

    so it's cruft

  72. stpeter

    we don't want people to come along and implement things that aren't in use and weren't such good ideas in the first place ;-)

  73. ralphm

    Do other standards organizations do a similar thing?

  74. stpeter

    sometimes, yes

  75. stpeter

    but e.g. the IETF has a lot more cruft than we do

  76. ralphm

    I'm just thinking aloud here, wether we should actively work to reduce the number of standards we have around, even if noone uses it anymore, as far as we know.

  77. stpeter

    they had an effort to clean out the cruft some years ago and it was overwhelming

  78. linuxwolf

    As long as the bar for cleaning up is very very high, I'm all for it

  79. Kev

    The reference to 130 could easily be removed from 172 at least.

  80. linuxwolf

    to the best of my knowledge, though, XEP-0130 didn't really solve the problem it set out to

  81. MattJ

    Wait... how did it get to be historical?

  82. ralphm

    jabber:iq:agents, maybe?

  83. stpeter

    MattJ: because it documented a protocol in use at the time

  84. MattJ

    Who used it?

  85. ralphm

    anyway, I'm +1 in this case

  86. ralphm

    Jabber Inc

  87. stpeter

    MattJ: France Telecom

  88. MattJ

    Ok

  89. ralphm

    with France Telecom, right?

  90. linuxwolf

    ralphm: correct

  91. stpeter

    JINC had support for it in XCP, but that support is gone

  92. Kev

    So we believe that the only people using it are now saying it's obsolete. That seems fine to me. Put out a ~Last Call and fine.

  93. stpeter

    Kev: rightio

  94. Kev

    4) The continuing shortification effort.

  95. Kev

    stpeter: You wanted to further discuss this?

  96. stpeter

    I didn't see people jumping up and down with excitement about my rough split of XEP-0045

  97. MattJ

    Indeed

  98. Kev

    I have it open in my browser, but haven't read it yet.

  99. linuxwolf

    I haven't finished reading it yet

  100. stpeter

    it's very rough, just to give a sense

  101. stpeter

    perhaps it's not worth the effort

  102. linuxwolf

    (well, I haven't started either (-: )

  103. MattJ

    I think the difference is less marked with XEP-0045, since it doesn't have a lot of optional features like pubsub

  104. linuxwolf

    /nod

  105. stpeter

    MattJ: perhaps

  106. ralphm

    I've looked at pubsub

  107. stpeter

    MattJ: revising XEP-0060 is on my to-do list for Life After IESG™

  108. ralphm

    Those many mandatory features are also tricky there

  109. ralphm

    it is ongoing work, that I plan to take my time on

  110. Kev

    I think it's much easier to split 60 than 45, but I'll give this split a read through.

  111. MattJ

    stpeter, there is life after IESG??

  112. linuxwolf

    stpeter: that should be a TV show (-:

  113. stpeter

    Kev: all right

  114. stpeter

    I haven't looked at 60

  115. Kev

    One thought I had is that if we do split 45, we should leave 45 in place with a reference to all three subXEPs, saying "You MUST implement all of these".

  116. stpeter

    will do in April, I think

  117. Kev

    That way the function of -45 doesn't change, but people could support just XEP-0313 or whatever, if that's deemed useful. Although I'm not sure yet that it is.

  118. ralphm

    Kev: that makes sense

  119. Kev

    Is there more to discuss on this right now, or shall we move on?

  120. stpeter

    move on

  121. Kev

    5) Date of next meeting.

  122. ralphm

    The same could go for XEP-0060, but I'm not that far to reach a conclusion on that yet.

  123. Kev

    Same old story?

  124. linuxwolf

    WFM

  125. ralphm

    +1

  126. MattJ

    wfm, though I'm terribly confused by all these changes :)

  127. MattJ

    and the fact that there was a meeting last week with no agenda

  128. stpeter

    heh

  129. MattJ

    I can't keep up

  130. linuxwolf

    (-:

  131. Kev

    MattJ: I thought we could meet in case there was AOB.

  132. stpeter

    what are the changes?

  133. MattJ

    Aren't the meetings usually Tuesday?

  134. Kev

    I was going to suggest we cancel, and then I realised that other people might come along with AOB for us and be horribly disappointed that we weren't here.

  135. Kev

    No, Wednesday, have been for aages :)

  136. Tobias

    +1 for same time

  137. stpeter

    they've been Wednesday

  138. Kev

    We did Tuesday for a brief while and then switched back.

  139. linuxwolf

    we did a couple of Tuesdays because I'm a git

  140. MattJ

    Well yes, it's been Wednesday forever

  141. MattJ

    (as far back as my memory goes)

  142. MattJ

    then we switch to Tuesday and I get used to it

  143. MattJ

    as long as I can blame linuxwolf it's fine

  144. Kev

    Ok, I'll assume we're on for SBTSBC then.

  145. Kev

    6) AOB?

  146. ralphm

    -

  147. MattJ

    nack

  148. stpeter

    calendar updated

  149. linuxwolf

    nay

  150. Kev

    Thanks Peter.

  151. Kev

    Ok, then I think we're done.

  152. Kev

    Thanks all.

  153. Kev

    Fini.

  154. stpeter

    BTW I shall fix up pubsub-since before publishing it

  155. linuxwolf

    and 6 minutes to spare (-:

  156. Tobias

    stpeter, btw any progress on the fosdem/summit recap for http://xmpp.org? anyway i could help?

  157. stpeter

    oh yeah

  158. Kev

    I'm applying for GSoC in between trying to get work done, BTW.

  159. Kev

    Florian's helping with some stuff.

  160. Kev

    We need to put out a call for ideas, once Florian's sorted out that page.

  161. MattJ

    Thanks Kev, +1 to GSoC if people can manage it :)

  162. stpeter

    Kev: are we working on the application via wiki or somesuch?

  163. Kev

    I was going to try and find last year's, and mostly duplicate it.

  164. Kev

    Do you want to help?

  165. stpeter

    yes

  166. stpeter

    although the mostly duplicate strategy sounds good

  167. stpeter

    I'll need something to occupy my time in Life After IESG™

  168. Kev

    Yees.

  169. ralphm

    Hmm, I notice both XEP-0045 and XEP-0060 are still Draft.

  170. Tobias

    yeah..we have just 11 final XEPs

  171. ralphm

    right, the observation makes me less nervous about splitting stuff up.

  172. MattJ

    Heh

  173. stpeter

    I was hoping we could push 45 to final less than 10 years after it went to draft, but probably no such luck

  174. Zash

    Criteria?

  175. Zash

    "been in the Draft state for at least six (6) months, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council."

  176. ralphm

    Zash: quoting XEP-0001 on us, huh?

  177. Zash

    ;P

  178. ralphm

    Seriously, though, it was never deemed ready for a vote, so far.