XMPP Council - 2010-03-29

  1. Tobias has joined
  2. Tobias has left
  3. Tobias has joined
  4. Tobias has left
  5. Tobias has joined
  6. Tobias has left
  7. Tobias has joined
  8. Tobias has left
  9. Tobias has joined
  10. Tobias has left
  11. Tobias has joined
  12. Tobias has left
  13. Tobias has joined
  14. Kev has left
  15. Kev !ping
  16. Tobias has left
  17. Kev has left
  18. Kev has left
  19. Kev has left
  20. Kev has left
  21. Kev has left
  22. Kev has left
  23. Kev has left
  24. Kev has left
  25. Kev has left
  26. Tobias has joined
  27. Kev has left
  28. Kev has left
  29. ralphm has joined
  30. ralphm waves
  31. Kev Hi Ralph.
  32. remko has joined
  33. Kev Hi Remko.
  34. remko hidiho
  35. Kev Give me 60 seconds to finish the iteam minutes, and see if Matt gets back in time.
  36. psa has joined
  37. psa howdy
  38. Kev Hi Peter. You should be relaxing :p
  39. psa :P
  40. remko hi peter
  41. psa mostly just catching up today
  42. psa lots of errands
  43. psa hi Remko!
  44. Kev Ok, let's get started and we can backpedal if Matt arrives in the next 3 minutes or so.
  45. ralphm I cleared out much of my unread mailinglist stuff
  46. Kev 1) Roll call. Kev, Ralph, Remko here, Matt probably not here with apologies.
  47. Kev ralphm: I think you're current, indeed, thanks.
  48. psa has 1750 messages in his inbox :(
  49. Kev 2) Agenda bashing.
  50. Kev Anyone?
  51. ralphm psa: I had over 3000
  52. psa ouch
  53. Kev I think I'm on ~1000. Only 257 threads with unread messages, though.
  54. Kev Anyway.
  55. Kev I'll assume that's a "no-bashing" :)
  56. remko no bashing
  57. Kev (Just had a 20minutes iteam meeting, going to try and beat that)
  58. psa heh
  59. Kev 3) XEP-0136: Message Archiving http://xmpp.org/extensions/tmp/xep-0136-1.2.html Diff: http://xmpp.org/extensions/diff/api/xep/0136/diff/1.1/vs/1.2rc1 Votes needed from Kev, Matt, Remko
  60. ralphm (I didn't actually read most of it)
  61. Kev Matt voted +1 today.
  62. remko i promise to vote on-list
  63. psa +1 given that today is a snipperdag for me ;-)
  64. Kev remko: today is the last day for voting on this.
  65. ralphm snipperdagen WTF
  66. remko psa: i have a snipperdag tomorrow ;-)
  67. remko kev: ok, in that case +0
  68. ralphm Matt did have some remarks
  69. remko well, +1 actually, i did read them
  70. Kev I'm unhappy with this, because it feels wrong.
  71. ralphm about the complexity
  72. Kev It feels complicated, and not fully thought out.
  73. Kev I don't have any one specific exception to it, though.
  74. psa nods
  75. remko kev: so, what do we do about this then?
  76. Kev My problem is that 136 was mostly workable before all this complexity, and was Draft. It's now going to be more complicated, without any interop testing and no idea how well it'll work.
  77. ralphm is it about the new stuff, the rewrite or the whole thing?
  78. psa naturally, most of it is too complicated
  79. ralphm (the complexity issues)
  80. Kev ralphm: it wasn't trivial to start with, but the new stuff feels very complex.
  81. psa looks at the author list
  82. psa all the Ian stuff is too complicated
  83. Kev remko: yes, that's the question, I'm debating whether to block it until I'm convinced it's sensible, or not.
  84. remko right
  85. ralphm Kev: so if you really feel it needs a second look, -1 it?
  86. remko the xep is already very complicated indeed
  87. Kev I don't want to be 'that guy' if it's just me and the world wants to move on.
  88. ralphm Kev: it is our job, really
  89. psa we've killed off most of that stuff -- looking forward to an end to XEP-0155 too
  90. Kev psa: as one of the authors, how do you feel about the complaints?
  91. psa the entire spec is too complex
  92. ralphm the spec or the protocol itself?
  93. psa clearly people have implemented it
  94. psa the protocol
  95. Kev psa: they've only implemented the old one though, haven't they?
  96. Kev I thought there was no server support for the new stuff.
  97. Kev If we've got interoperable implementations, I don't have much of an argument to have.
  98. psa Alexander and Yann have implemented the new stuff AFAIK, in ejabberd and gajim respectively
  99. remko i thought there was
  100. Kev Ah.
  101. ralphm do the implementations implement all of the (old) aspects
  102. ralphm ?
  103. psa ralphm: that, I'm not sure
  104. psa ralphm: quite possibly not
  105. ralphm I mean, if most of the complexity is not implemented, maybe we can cut stuff there?
  106. Kev I'll +0 it, then, but can we attach a Council note saying that I'm uncomfortable with the complexity, and that it should have a review and possible simplification if needed?
  107. psa the XSF needs an interoperability process so that we can reduce complexity before pushing things to Final
  108. fippo has joined
  109. ralphm psa: yeah
  110. remko i'm +0ing too
  111. psa Kev: that does not seem unreasonable
  112. psa IMHO we need to take a close look at this one
  113. Kev Excellent, thanks.
  114. psa and simplify
  115. ralphm so that basically means that we are now accepting the changes but don't like it?
  116. Kev This is something I do actually care about - server side history is great.
  117. psa right now the protocol has too many bells and whistles and options
  118. remko *nod*
  119. Kev ralphm: if half of council are in favour of the changes (you and Matt), half of Council don't like it, but don't have a specific complaint to block with (Remko and me), and there are interoperable implementations of the new stuff...I think that's a good summary, yeah.
  120. psa as a first step, I think we need to gather a list of implementations (not sure if Google ever implemented it with this namespace) and poll them regarding which particular features they implement
  121. ralphm Kev: I'm ok with the changes, yes. On the complexity, maybe the whole thing needs to be reconsidered
  122. psa ralphm: yeah
  123. Kev psa: I think that'd be good.
  124. psa so perhaps the Council can write up a note that we can add to the spec
  125. Kev There's also scope for a Simplified Message Archiving spec if such a thing is needed, or whatever.
  126. ralphm so a Call for Experience
  127. Kev psa: I'll take that action.
  128. Kev ralphm: only with a little c, because it's not a CfE :)
  129. Kev Or are we allowed to issue those without advancement?
  130. psa ralphm: well, we issue a CfE only when we want to move ot Final
  131. ralphm sure we can
  132. psa hmm
  133. Kev In any case, yes.
  134. Kev I'll write a note, and we'll ask for experience.
  135. psa we *have* issued those only before advancing to Final
  136. Kev 14 minutes gone, let's get a wriggle on :)
  137. ralphm we want to move this eventually, and as-is we don't seem to like it much
  138. psa doesn't mean we couldn't do so under other circumstances
  139. Kev 4) XEP-0184: Message Receipts http://xmpp.org/extensions/tmp/xep-0184-1.1.html http://xmpp.org/extensions/diff/api/xep/0184/diff/1.0/vs/1.1rc7 Updated to reflect Kev's objections. Accept 1.1rc7?
  140. Kev I'm +1 after the latest changes.
  141. Kev Ralph's already +1d
  142. psa I like it much better now
  143. psa Kev's criticisms were quite warranted
  144. ralphm good changes, indeed
  145. remko kev: is there still time to vote for this tomorrow for me?
  146. Kev remko: yes, voting on this starts tonight, you've got a fortnight.
  147. remko ok
  148. Kev 5) Distributed MUC http://www.xmpp.org/extensions/inbox/dmuc2.html Another distributed MUC proposal - accept as Experimental?
  149. remko +1
  150. Kev Would it be better to accept this as a competing Experimental, or have the XEP authors work together on the existing Experimental?
  151. psa just realized he has an "AOB" item
  152. Kev I'm not opposed to either approach.
  153. Kev psa / fippo: what are your thoughts?
  154. ralphm I prefer both
  155. remko i don't mind publishing this as an experimental for aske of history, and then merging both
  156. psa I admit that I didn't get to read fippo's document as I had hoped to on the flight back from IETF 77
  157. remko s/aske/sake/
  158. Kev psa: I have comments on both dmucs, but I'm happy to have both on the vine.
  159. Kev So I'm not not objecting to publishing.
  160. psa I like to publish documents :)
  161. psa as is well-known
  162. Kev Ok.
  163. psa in the early days we had 3 or 4 pubsub specs, as Ralph no doubt recalls
  164. ralphm dmuc2 is not complete yet. I am especially interested in the netsplit/join stuff
  165. ralphm psa: indeed
  166. Kev psa: and you added all four together to get the monster we have now? :)
  167. psa dmuc1 is not complete, either
  168. ralphm psa: sure
  169. Kev No, both are WIPs
  170. lynX has joined
  171. Kev Anyway, shall we move onto 6) Fifth member. Nathan and Jack standing.
  172. ralphm Kev: actually, no. The first pubsub spec worked with IQs :-)
  173. ralphm Where are they standing?
  174. Kev Shush.
  175. ralphm :-P
  176. Kev I'm sure either Jack or Fritzy would be a fine fifth member.
  177. ralphm indeed
  178. psa [oh, I have two AOB items...]
  179. psa Kev: as am I
  180. Kev Given that Jack's done this before, and he's on Board, I'm inclined to suggest Nathan for some fresh perspective, and to avoid getting too inbred, but I'd be very happy with either.
  181. remko same comment from me.
  182. remko it also seemed that jack was willing to do this more as a fallback, but i might be wrong
  183. Kev I asked Fabio as well, as he applied at the start of the session, but he's snowed under at the moment.
  184. psa despite the fact that I lack a vote in the matter, I agree with the sentiment of having new people on the Council -- it's a form of recycling
  185. Kev ralphm: what think you on Jack and Nathan?
  186. ralphm Kev: I had the same feeling
  187. ralphm and I'm sure Jack just wants the spot filled
  188. Kev Ok, we'll wait for Matt to express an opinion on-list, but that looks like Fritzy unless some terrible secret comes forward.
  189. psa heh
  190. Kev Ok, AOB. I believe someone's waiting in the wings with two items...
  191. psa starts the "Fritzy is a spy!" meme
  192. ralphm since there is no actual process, do we vote or is it a humming thing?
  193. psa ok, AOB
  194. Kev ralphm: we vote. I'm assuming that until Matt votes we have the chance to revoke our previous votes, though, thus not taking it as done yet.
  195. ralphm ok
  196. Kev points at his presence.
  197. psa I think it's a vote but that's not explicit at http://xmpp.org/council/policies.shtml
  198. psa ok
  199. psa first AOB, Thursday is April 1 :P
  200. Kev psa: when I checked the bylaws, I believe it said 'vote'
  201. remko oh no
  202. remko will we be fooled again?
  203. psa so I might cook something up for April 1, but I haven't come up with anything yet
  204. Kev remko: Guess who I'm listening to at the moment ;)
  205. ralphm and select a new member from among the applicants.
  206. Kev psa: OK. It's not strictly vital to have an AFD post, you know.
  207. psa last week was busy (as were all the weeks leading up to IETF 77)
  208. psa Kev: true -- I prefer quality over quantity
  209. psa second AOB
  210. remko don't leave us hanging here
  211. psa at IETF 77 I met with a guy who has an implementation of http://xmpp.org/extensions/inbox/sxe.html for whiteboarding (so that includes http://xmpp.org/extensions/inbox/whiteboard.html I suppose)
  212. psa and he is working on fixes to that spec
  213. Kev Oh, great.
  214. remko excellent, taht spec needed some love
  215. psa in fact I heard from someone else recently who has implemented it
  216. ralphm this is the muc based one, yeah?
  217. psa ralphm: it can go through MUC
  218. psa the guy I met with implemented it over link-local
  219. psa ralphm: but it doesn't need to go over MUC
  220. ralphm ah
  221. psa anyway, I wanted you guys to know that we might have a revised version to consider soon for publication
  222. ralphm cool
  223. Kev I seem to recall that we had discussions about this at Fosdem.
  224. psa that's it from me
  225. Kev Although possibly it was at dinner.
  226. psa Kev: I don't recall discussions, but I wasn't there on Friday
  227. Kev Oh, I remember
  228. Kev It was how you can use whiteboarding over muc assuming the muc knows nothing about whiteboarding
  229. psa yes
  230. Kev but if you /do/ have a whiteboarding-enabled muc, it can make things much better for people joining an active whiteboard later.
  231. psa right
  232. Kev Ok, that's easy to put into any spec.
  233. ralphm I am wondering if the suggestions around pubsub in mucs would help this effort
  234. Kev So, we've a minute over my half hour tolerance.
  235. psa nothing more from me
  236. Kev Unless there are any other other businesses, I suggest we close.
  237. psa next meeting?
  238. Kev OH, next ...
  239. Kev right
  240. Kev same time next week?
  241. ralphm next week
  242. Kev Ah, no.
  243. Kev It's Easter Monday.
  244. Kev Shall we treat ourselves to a week off?
  245. ralphm ok
  246. Kev Next meeting same time a fortnight today, then.
  247. remko sounds good
  248. psa WFM
  249. Kev Excellent, thanks all.
  250. Kev bangs the gavel.
  251. remko thanks
  252. psa thanks guys
  253. psa wanders off to heat up some lunch
  254. Kev I'll sort out minutes before too long.
  255. psa thanks
  256. psa I'll soon go back to being offline :)
  257. ralphm psa: noooo
  258. ralphm psa: about XEP-0060, the remarks around node deletion with redirect are basically this:
  259. ralphm 1) it uses jid/node attributes, rather than the uri thing I have implemented
  260. ralphm 2) There is no mention of the <redirect/> being sent along with notifications.
  261. ralphm actually I only implemented 2 with a <delete node='test'><redirect uri='xmpp:example.org?;node=test2'></delete>
  262. ralphm and did not implement the stuff for requesting delete with redirect, because that's internal to my implementation
  263. psa ok
  264. ralphm I am not really wedded to using URIs, per se
  265. remko has left
  266. psa URI is consistent with http://xmpp.org/extensions/tmp/xep-0060-1.13.html#example-44
  267. ralphm except that is not allowed by Core
  268. psa i.e., the <gone/> error in XMPP core
  269. ralphm 'cause that mentions that the character data must be a JID
  270. psa even in bis?
  271. ralphm no in 3920
  272. ralphm I think URI is better, but then we need to grandfather JIDs in
  273. mlundblad has joined
  274. ralphm (e.g. by accepting schema-less URIs)
  275. psa yes
  276. ralphm a redirect on node acces example should be in XEP-0060, next to the one you linked to
  277. ralphm and then we now get to decide on using URIs or jid/node for the delete+redirect request and notification
  278. psa what do you mean by "2) There is no mention of the <redirect/> being sent along with notifications."?
  279. ralphm in a delete event notification sent out to (former) subscribers of the node
  280. ralphm it should include the redirect
  281. psa you mean at http://xmpp.org/extensions/tmp/xep-0060-1.13.html#example-158
  282. psa yes
  283. psa we need the redirect there
  284. ralphm this is essential for making redirects work
  285. ralphm yes
  286. ralphm so /that/ is actually the only thing I implemented
  287. psa that = with <redirect/> ?
  288. psa er
  289. psa without
  290. Kev has left
  291. ralphm delete notification with redirect
  292. psa ok
  293. psa that's better
  294. psa (if a redirect is in place, naturally :)
  295. ralphm I didn't implement 8.4.1
  296. ralphm because node deletion is internal to my implementation
  297. ralphm yes, of course it is optional
  298. Kev has left
  299. ralphm so with jid/node it would look like this:
  300. ralphm <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <delete node='princely_musings'>/> </event> </message>
  301. ralphm oops
  302. ralphm <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <delete node='princely_musings'> <redirect jid='pubsub.shakespeare.lit' node='something_else'/> </delete> </event> </message>
  303. ralphm vs.
  304. ralphm <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <delete node='princely_musings'> <redirect uri='xmpp:pubsub.shakespeare.lit?;node=something_else'/> </delete> </event> </message>
  305. psa right
  306. ralphm Using URIs has the potential of hybrid protocol solutions
  307. ralphm I am not sure if we need to cater for that
  308. ralphm the only reason to use URIs in the error element is because it requires character data
  309. psa true
  310. ralphm and URIs are an easy way to specify JID+node
  311. psa they look funny, but they are easy :)
  312. ralphm it is still too bad the first element is required (even if it may be empty)
  313. ralphm anyway, in the end I have no real preference
  314. psa shrugs
  315. ralphm the uri stuff is currently in wokkel
  316. ralphm but the only working deployment is under my control
  317. ralphm (that I know of)
  318. psa I think URIs are preferable simply because new subscribers are going to receive an XMPP <gone/> error with a URI anyway (under 3920bis)
  319. psa the lack of a <redirect/> error in the examples right now is a simple spec bug so I will fix that
  320. psa s/error/element/
  321. ralphm ok, let's go with URIs then
  322. psa +1
  323. ralphm leaves the possibility to go to PuSH or some other fancy other thing
  324. psa yep
  325. ralphm now I am going to relax a bit. Have a good snipperdag!
  326. psa :)
  327. psa ralphm: where do we stand on IQ notifications?
  328. ralphm oh, nobody replied to my post
  329. psa ah I see it
  330. psa I'll try to do that tomorrow
  331. psa starts a reply as a reminder
  332. psa thanks for the reply
  333. ralphm drop me a line to chat on it, if needed
  334. psa ok
  335. psa will do
  336. ralphm cool
  337. psa now, back to our regularly schedule snipperdag :)
  338. ralphm :-)
  339. psa +d
  340. psa thanks, Ralph!
  341. ralphm and you
  342. psa disappears in a puff of smoke ;-)
  343. psa has left
  344. ralphm has left
  345. fippo has left
  346. Tobias has left
  347. Tobias has joined
  348. Tobias has left