XMPP Council - 2010-03-29

  1. Kev


  2. ralphm waves

  3. Kev

    Hi Ralph.

  4. Kev

    Hi Remko.

  5. remko


  6. Kev

    Give me 60 seconds to finish the iteam minutes, and see if Matt gets back in time.

  7. psa


  8. Kev

    Hi Peter. You should be relaxing :p

  9. psa


  10. remko

    hi peter

  11. psa

    mostly just catching up today

  12. psa

    lots of errands

  13. psa

    hi Remko!

  14. Kev

    Ok, let's get started and we can backpedal if Matt arrives in the next 3 minutes or so.

  15. ralphm

    I cleared out much of my unread mailinglist stuff

  16. Kev

    1) Roll call. Kev, Ralph, Remko here, Matt probably not here with apologies.

  17. Kev

    ralphm: I think you're current, indeed, thanks.

  18. psa has 1750 messages in his inbox :(

  19. Kev

    2) Agenda bashing.

  20. Kev


  21. ralphm

    psa: I had over 3000

  22. psa


  23. Kev

    I think I'm on ~1000. Only 257 threads with unread messages, though.

  24. Kev


  25. Kev

    I'll assume that's a "no-bashing" :)

  26. remko

    no bashing

  27. Kev

    (Just had a 20minutes iteam meeting, going to try and beat that)

  28. psa


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

  30. ralphm

    (I didn't actually read most of it)

  31. Kev

    Matt voted +1 today.

  32. remko

    i promise to vote on-list

  33. psa

    +1 given that today is a snipperdag for me ;-)

  34. Kev

    remko: today is the last day for voting on this.

  35. ralphm

    snipperdagen WTF

  36. remko

    psa: i have a snipperdag tomorrow ;-)

  37. remko

    kev: ok, in that case +0

  38. ralphm

    Matt did have some remarks

  39. remko

    well, +1 actually, i did read them

  40. Kev

    I'm unhappy with this, because it feels wrong.

  41. ralphm

    about the complexity

  42. Kev

    It feels complicated, and not fully thought out.

  43. Kev

    I don't have any one specific exception to it, though.

  44. psa nods

  45. remko

    kev: so, what do we do about this then?

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

  47. ralphm

    is it about the new stuff, the rewrite or the whole thing?

  48. psa

    naturally, most of it is too complicated

  49. ralphm

    (the complexity issues)

  50. Kev

    ralphm: it wasn't trivial to start with, but the new stuff feels very complex.

  51. psa looks at the author list

  52. psa

    all the Ian stuff is too complicated

  53. Kev

    remko: yes, that's the question, I'm debating whether to block it until I'm convinced it's sensible, or not.

  54. remko


  55. ralphm

    Kev: so if you really feel it needs a second look, -1 it?

  56. remko

    the xep is already very complicated indeed

  57. Kev

    I don't want to be 'that guy' if it's just me and the world wants to move on.

  58. ralphm

    Kev: it is our job, really

  59. psa

    we've killed off most of that stuff -- looking forward to an end to XEP-0155 too

  60. Kev

    psa: as one of the authors, how do you feel about the complaints?

  61. psa

    the entire spec is too complex

  62. ralphm

    the spec or the protocol itself?

  63. psa

    clearly people have implemented it

  64. psa

    the protocol

  65. Kev

    psa: they've only implemented the old one though, haven't they?

  66. Kev

    I thought there was no server support for the new stuff.

  67. Kev

    If we've got interoperable implementations, I don't have much of an argument to have.

  68. psa

    Alexander and Yann have implemented the new stuff AFAIK, in ejabberd and gajim respectively

  69. remko

    i thought there was

  70. Kev


  71. ralphm

    do the implementations implement all of the (old) aspects

  72. ralphm


  73. psa

    ralphm: that, I'm not sure

  74. psa

    ralphm: quite possibly not

  75. ralphm

    I mean, if most of the complexity is not implemented, maybe we can cut stuff there?

  76. 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?

  77. psa

    the XSF needs an interoperability process so that we can reduce complexity before pushing things to Final

  78. ralphm

    psa: yeah

  79. remko

    i'm +0ing too

  80. psa

    Kev: that does not seem unreasonable

  81. psa

    IMHO we need to take a close look at this one

  82. Kev

    Excellent, thanks.

  83. psa

    and simplify

  84. ralphm

    so that basically means that we are now accepting the changes but don't like it?

  85. Kev

    This is something I do actually care about - server side history is great.

  86. psa

    right now the protocol has too many bells and whistles and options

  87. remko


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

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

  90. ralphm

    Kev: I'm ok with the changes, yes. On the complexity, maybe the whole thing needs to be reconsidered

  91. psa

    ralphm: yeah

  92. Kev

    psa: I think that'd be good.

  93. psa

    so perhaps the Council can write up a note that we can add to the spec

  94. Kev

    There's also scope for a Simplified Message Archiving spec if such a thing is needed, or whatever.

  95. ralphm

    so a Call for Experience

  96. Kev

    psa: I'll take that action.

  97. Kev

    ralphm: only with a little c, because it's not a CfE :)

  98. Kev

    Or are we allowed to issue those without advancement?

  99. psa

    ralphm: well, we issue a CfE only when we want to move ot Final

  100. ralphm

    sure we can

  101. psa


  102. Kev

    In any case, yes.

  103. Kev

    I'll write a note, and we'll ask for experience.

  104. psa

    we *have* issued those only before advancing to Final

  105. Kev

    14 minutes gone, let's get a wriggle on :)

  106. ralphm

    we want to move this eventually, and as-is we don't seem to like it much

  107. psa

    doesn't mean we couldn't do so under other circumstances

  108. 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?

  109. Kev

    I'm +1 after the latest changes.

  110. Kev

    Ralph's already +1d

  111. psa

    I like it much better now

  112. psa

    Kev's criticisms were quite warranted

  113. ralphm

    good changes, indeed

  114. remko

    kev: is there still time to vote for this tomorrow for me?

  115. Kev

    remko: yes, voting on this starts tonight, you've got a fortnight.

  116. remko


  117. Kev

    5) Distributed MUC http://www.xmpp.org/extensions/inbox/dmuc2.html Another distributed MUC proposal - accept as Experimental?

  118. remko


  119. Kev

    Would it be better to accept this as a competing Experimental, or have the XEP authors work together on the existing Experimental?

  120. psa just realized he has an "AOB" item

  121. Kev

    I'm not opposed to either approach.

  122. Kev

    psa / fippo: what are your thoughts?

  123. ralphm

    I prefer both

  124. remko

    i don't mind publishing this as an experimental for aske of history, and then merging both

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

  126. remko


  127. Kev

    psa: I have comments on both dmucs, but I'm happy to have both on the vine.

  128. Kev

    So I'm not not objecting to publishing.

  129. psa

    I like to publish documents :)

  130. psa

    as is well-known

  131. Kev


  132. psa

    in the early days we had 3 or 4 pubsub specs, as Ralph no doubt recalls

  133. ralphm

    dmuc2 is not complete yet. I am especially interested in the netsplit/join stuff

  134. ralphm

    psa: indeed

  135. Kev

    psa: and you added all four together to get the monster we have now? :)

  136. psa

    dmuc1 is not complete, either

  137. ralphm

    psa: sure

  138. Kev

    No, both are WIPs

  139. Kev

    Anyway, shall we move onto 6) Fifth member. Nathan and Jack standing.

  140. ralphm

    Kev: actually, no. The first pubsub spec worked with IQs :-)

  141. ralphm

    Where are they standing?

  142. Kev


  143. ralphm


  144. Kev

    I'm sure either Jack or Fritzy would be a fine fifth member.

  145. ralphm


  146. psa

    [oh, I have two AOB items...]

  147. psa

    Kev: as am I

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

  149. remko

    same comment from me.

  150. remko

    it also seemed that jack was willing to do this more as a fallback, but i might be wrong

  151. Kev

    I asked Fabio as well, as he applied at the start of the session, but he's snowed under at the moment.

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

  153. Kev

    ralphm: what think you on Jack and Nathan?

  154. ralphm

    Kev: I had the same feeling

  155. ralphm

    and I'm sure Jack just wants the spot filled

  156. Kev

    Ok, we'll wait for Matt to express an opinion on-list, but that looks like Fritzy unless some terrible secret comes forward.

  157. psa


  158. Kev

    Ok, AOB. I believe someone's waiting in the wings with two items...

  159. psa starts the "Fritzy is a spy!" meme

  160. ralphm

    since there is no actual process, do we vote or is it a humming thing?

  161. psa

    ok, AOB

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

  163. ralphm


  164. Kev points at his presence.

  165. psa

    I think it's a vote but that's not explicit at http://xmpp.org/council/policies.shtml

  166. psa


  167. psa

    first AOB, Thursday is April 1 :P

  168. Kev

    psa: when I checked the bylaws, I believe it said 'vote'

  169. remko

    oh no

  170. remko

    will we be fooled again?

  171. psa

    so I might cook something up for April 1, but I haven't come up with anything yet

  172. Kev

    remko: Guess who I'm listening to at the moment ;)

  173. ralphm

    and select a new member from among the applicants.

  174. Kev

    psa: OK. It's not strictly vital to have an AFD post, you know.

  175. psa

    last week was busy (as were all the weeks leading up to IETF 77)

  176. psa

    Kev: true -- I prefer quality over quantity

  177. psa

    second AOB

  178. remko

    don't leave us hanging here

  179. 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)

  180. psa

    and he is working on fixes to that spec

  181. Kev

    Oh, great.

  182. remko

    excellent, taht spec needed some love

  183. psa

    in fact I heard from someone else recently who has implemented it

  184. ralphm

    this is the muc based one, yeah?

  185. psa

    ralphm: it can go through MUC

  186. psa

    the guy I met with implemented it over link-local

  187. psa

    ralphm: but it doesn't need to go over MUC

  188. ralphm


  189. psa

    anyway, I wanted you guys to know that we might have a revised version to consider soon for publication

  190. ralphm


  191. Kev

    I seem to recall that we had discussions about this at Fosdem.

  192. psa

    that's it from me

  193. Kev

    Although possibly it was at dinner.

  194. psa

    Kev: I don't recall discussions, but I wasn't there on Friday

  195. Kev

    Oh, I remember

  196. Kev

    It was how you can use whiteboarding over muc assuming the muc knows nothing about whiteboarding

  197. psa


  198. Kev

    but if you /do/ have a whiteboarding-enabled muc, it can make things much better for people joining an active whiteboard later.

  199. psa


  200. Kev

    Ok, that's easy to put into any spec.

  201. ralphm

    I am wondering if the suggestions around pubsub in mucs would help this effort

  202. Kev

    So, we've a minute over my half hour tolerance.

  203. psa

    nothing more from me

  204. Kev

    Unless there are any other other businesses, I suggest we close.

  205. psa

    next meeting?

  206. Kev

    OH, next ...

  207. Kev


  208. Kev

    same time next week?

  209. ralphm

    next week

  210. Kev

    Ah, no.

  211. Kev

    It's Easter Monday.

  212. Kev

    Shall we treat ourselves to a week off?

  213. ralphm


  214. Kev

    Next meeting same time a fortnight today, then.

  215. remko

    sounds good

  216. psa


  217. Kev

    Excellent, thanks all.

  218. Kev bangs the gavel.

  219. remko


  220. psa

    thanks guys

  221. psa wanders off to heat up some lunch

  222. Kev

    I'll sort out minutes before too long.

  223. psa


  224. psa

    I'll soon go back to being offline :)

  225. ralphm

    psa: noooo

  226. ralphm

    psa: about XEP-0060, the remarks around node deletion with redirect are basically this:

  227. ralphm

    1) it uses jid/node attributes, rather than the uri thing I have implemented

  228. ralphm

    2) There is no mention of the <redirect/> being sent along with notifications.

  229. ralphm

    actually I only implemented 2 with a <delete node='test'><redirect uri='xmpp:example.org?;node=test2'></delete>

  230. ralphm

    and did not implement the stuff for requesting delete with redirect, because that's internal to my implementation

  231. psa


  232. ralphm

    I am not really wedded to using URIs, per se

  233. psa

    URI is consistent with http://xmpp.org/extensions/tmp/xep-0060-1.13.html#example-44

  234. ralphm

    except that is not allowed by Core

  235. psa

    i.e., the <gone/> error in XMPP core

  236. ralphm

    'cause that mentions that the character data must be a JID

  237. psa

    even in bis?

  238. ralphm

    no in 3920

  239. ralphm

    I think URI is better, but then we need to grandfather JIDs in

  240. ralphm

    (e.g. by accepting schema-less URIs)

  241. psa


  242. ralphm

    a redirect on node acces example should be in XEP-0060, next to the one you linked to

  243. ralphm

    and then we now get to decide on using URIs or jid/node for the delete+redirect request and notification

  244. psa

    what do you mean by "2) There is no mention of the <redirect/> being sent along with notifications."?

  245. ralphm

    in a delete event notification sent out to (former) subscribers of the node

  246. ralphm

    it should include the redirect

  247. psa

    you mean at http://xmpp.org/extensions/tmp/xep-0060-1.13.html#example-158

  248. psa


  249. psa

    we need the redirect there

  250. ralphm

    this is essential for making redirects work

  251. ralphm


  252. ralphm

    so /that/ is actually the only thing I implemented

  253. psa

    that = with <redirect/> ?

  254. psa


  255. psa


  256. ralphm

    delete notification with redirect

  257. psa


  258. psa

    that's better

  259. psa

    (if a redirect is in place, naturally :)

  260. ralphm

    I didn't implement 8.4.1

  261. ralphm

    because node deletion is internal to my implementation

  262. ralphm

    yes, of course it is optional

  263. ralphm

    so with jid/node it would look like this:

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

  265. ralphm


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

  267. ralphm


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

  269. psa


  270. ralphm

    Using URIs has the potential of hybrid protocol solutions

  271. ralphm

    I am not sure if we need to cater for that

  272. ralphm

    the only reason to use URIs in the error element is because it requires character data

  273. psa


  274. ralphm

    and URIs are an easy way to specify JID+node

  275. psa

    they look funny, but they are easy :)

  276. ralphm

    it is still too bad the first element is required (even if it may be empty)

  277. ralphm

    anyway, in the end I have no real preference

  278. psa shrugs

  279. ralphm

    the uri stuff is currently in wokkel

  280. ralphm

    but the only working deployment is under my control

  281. ralphm

    (that I know of)

  282. psa

    I think URIs are preferable simply because new subscribers are going to receive an XMPP <gone/> error with a URI anyway (under 3920bis)

  283. psa

    the lack of a <redirect/> error in the examples right now is a simple spec bug so I will fix that

  284. psa


  285. ralphm

    ok, let's go with URIs then

  286. psa


  287. ralphm

    leaves the possibility to go to PuSH or some other fancy other thing

  288. psa


  289. ralphm

    now I am going to relax a bit. Have a good snipperdag!

  290. psa


  291. psa

    ralphm: where do we stand on IQ notifications?

  292. ralphm

    oh, nobody replied to my post

  293. psa

    ah I see it

  294. psa

    I'll try to do that tomorrow

  295. psa starts a reply as a reminder

  296. psa

    thanks for the reply

  297. ralphm

    drop me a line to chat on it, if needed

  298. psa


  299. psa

    will do

  300. ralphm


  301. psa

    now, back to our regularly schedule snipperdag :)

  302. ralphm


  303. psa


  304. psa

    thanks, Ralph!

  305. ralphm

    and you

  306. psa disappears in a puff of smoke ;-)