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