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