XMPP Council - 2012-02-29


  1. Tobias has left

  2. stpeter has left

  3. Kev has left

  4. linuxwolf has joined

  5. linuxwolf has left

  6. linuxwolf has joined

  7. linuxwolf has left

  8. Kev has joined

  9. Tobias has joined

  10. Tobias has left

  11. Kev has left

  12. Kev has joined

  13. Kev has left

  14. Kev has joined

  15. Tobias has joined

  16. Neustradamus has left

  17. Neustradamus has left

  18. Tobias has left

  19. Tobias has joined

  20. Tobias has left

  21. Tobias has joined

  22. linuxwolf has joined

  23. Tobias has left

  24. stpeter has joined

  25. ralphm has joined

  26. ralphm waves

  27. Kev

    Hi Ralph.

  28. Kev

    I haven't even forgotten. Yet :)

  29. ralphm

    heh

  30. ralphm

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

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

  32. linuxwolf

    oopsie

  33. ralphm

    yeah, that too (last week)

  34. Kev

    Howdy folks.

  35. Kev

    1) Bap call.

  36. Kev

    I'm here.

  37. Tobias too

  38. linuxwolf

    presente

  39. stpeter

    Matthew seems to be offline

  40. Zash has joined

  41. ralphm is here

  42. ralphm

    stpeter: I still don't see it

  43. Kev

    Marrrrvellous.

  44. linuxwolf

    his server seems to be gone

  45. linuxwolf

    /-:

  46. Kev

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

  47. Kev

    Accept as XEP?

  48. ralphm

    +1

  49. linuxwolf

    +1

  50. MattJ has joined

  51. ralphm

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

  52. stpeter

    ralphm: true

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

  54. MattJ

    +1... but... timestamps.

  55. Tobias

    +1

  56. stpeter

    by "timestamps" do you mean UTC?

  57. ralphm

    clock skew

  58. stpeter

    instead of last presence?

  59. stpeter

    I just used the format from iq:last

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

  61. MattJ

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

  62. Kev

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

  63. Tobias

    Kev, what exactly has been proven not to work?

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

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

  66. ralphm

    /not/ idempotent

  67. Tobias

    Kev, ah..right

  68. Kev

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

  69. ralphm

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

  70. Kev

    (using pubsub-since)

  71. Kev

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

  72. ralphm

    well, it is not an active standard yet

  73. Kev

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

  74. ralphm

    I'm not against publishing

  75. linuxwolf

    no one is asking to push it to draft yet

  76. Tobias

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

  77. Kev

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

  78. Kev

    3) Obsoleting 130.

  79. linuxwolf

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

  80. Kev

    linuxwolf: Reasonable.

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

  82. stpeter

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

  83. MattJ

    +1 to -0130

  84. ralphm

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

  85. linuxwolf

    also +1 to −0130

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

  87. stpeter

    Kev: for sure

  88. linuxwolf

    of course

  89. Kev

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

  90. Tobias

    Kev, sounds like a good idea

  91. MattJ

    linuxwolf, I like what you did there :)

  92. stpeter

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

  93. Kev

    Ah, I'd completely forgotten that was there.

  94. Kev

    Fairy nerfs, then.

  95. ralphm

    what is the necessity of obsoleting this specification?

  96. stpeter

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

  97. stpeter

    ralphm: second, no one is using it

  98. stpeter

    so it's cruft

  99. 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 ;-)

  100. ralphm

    Do other standards organizations do a similar thing?

  101. stpeter

    sometimes, yes

  102. stpeter

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

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

  104. stpeter

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

  105. linuxwolf

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

  106. Kev

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

  107. linuxwolf

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

  108. MattJ

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

  109. ralphm

    jabber:iq:agents, maybe?

  110. stpeter

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

  111. MattJ

    Who used it?

  112. ralphm

    anyway, I'm +1 in this case

  113. ralphm

    Jabber Inc

  114. stpeter

    MattJ: France Telecom

  115. MattJ

    Ok

  116. ralphm

    with France Telecom, right?

  117. linuxwolf

    ralphm: correct

  118. stpeter

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

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

  120. stpeter

    Kev: rightio

  121. Kev

    4) The continuing shortification effort.

  122. Kev

    stpeter: You wanted to further discuss this?

  123. stpeter

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

  124. MattJ

    Indeed

  125. Kev

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

  126. linuxwolf

    I haven't finished reading it yet

  127. stpeter

    it's very rough, just to give a sense

  128. stpeter

    perhaps it's not worth the effort

  129. linuxwolf

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

  130. MattJ

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

  131. linuxwolf

    /nod

  132. stpeter

    MattJ: perhaps

  133. ralphm

    I've looked at pubsub

  134. stpeter

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

  135. ralphm

    Those many mandatory features are also tricky there

  136. ralphm

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

  137. Kev

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

  138. MattJ

    stpeter, there is life after IESG??

  139. linuxwolf

    stpeter: that should be a TV show (-:

  140. stpeter

    Kev: all right

  141. stpeter

    I haven't looked at 60

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

  143. stpeter

    will do in April, I think

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

  145. ralphm

    Kev: that makes sense

  146. Kev

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

  147. stpeter

    move on

  148. Kev

    5) Date of next meeting.

  149. ralphm

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

  150. Kev

    Same old story?

  151. linuxwolf

    WFM

  152. ralphm

    +1

  153. MattJ

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

  154. MattJ

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

  155. stpeter

    heh

  156. MattJ

    I can't keep up

  157. linuxwolf

    (-:

  158. Kev

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

  159. stpeter

    what are the changes?

  160. MattJ

    Aren't the meetings usually Tuesday?

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

  162. Kev

    No, Wednesday, have been for aages :)

  163. Tobias

    +1 for same time

  164. stpeter

    they've been Wednesday

  165. Kev

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

  166. linuxwolf

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

  167. MattJ

    Well yes, it's been Wednesday forever

  168. MattJ

    (as far back as my memory goes)

  169. MattJ

    then we switch to Tuesday and I get used to it

  170. MattJ

    as long as I can blame linuxwolf it's fine

  171. Kev

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

  172. Kev

    6) AOB?

  173. ralphm

    -

  174. MattJ

    nack

  175. stpeter

    calendar updated

  176. linuxwolf

    nay

  177. Kev

    Thanks Peter.

  178. Kev

    Ok, then I think we're done.

  179. Kev

    Thanks all.

  180. Kev

    Fini.

  181. stpeter

    BTW I shall fix up pubsub-since before publishing it

  182. linuxwolf

    and 6 minutes to spare (-:

  183. Tobias

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

  184. stpeter

    oh yeah

  185. Kev

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

  186. Kev

    Florian's helping with some stuff.

  187. Kev

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

  188. MattJ

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

  189. linuxwolf has left

  190. linuxwolf has joined

  191. stpeter

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

  192. Kev

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

  193. Kev

    Do you want to help?

  194. stpeter

    yes

  195. stpeter

    although the mostly duplicate strategy sounds good

  196. stpeter

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

  197. Kev

    Yees.

  198. ralphm has left

  199. ralphm has joined

  200. ralphm

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

  201. Tobias

    yeah..we have just 11 final XEPs

  202. ralphm

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

  203. MattJ

    Heh

  204. stpeter

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

  205. Zash

    Criteria?

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

  207. ralphm

    Zash: quoting XEP-0001 on us, huh?

  208. Zash

    ;P

  209. ralphm

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

  210. linuxwolf has left

  211. linuxwolf has joined

  212. linuxwolf has left

  213. linuxwolf has joined

  214. linuxwolf has left

  215. Tobias has left