XMPP Council - 2010-05-03

  1. Kev

    50 minutes

  2. MattJ

    If I'm not around when the meeting starts, proceed without me, and I'll vote on-list

  3. Kev


  4. MattJ has spent most of the last 48 hours unwell in bed :(

  5. Kev

    That sounds inefficient.

  6. MattJ


  7. Fritzy

    get well

  8. Kev

    That too.

  9. MattJ

    Thanks :)

  10. MattJ

    I'm recovering, had today been yesterday though I wouldn't have remembered the metting at all

  11. MattJ

    or the meeting

  12. Fritzy

    that's the thing about yesterday

  13. ralphm materializes out of thin air

  14. Kev


  15. Kev

    Ok then.

  16. Kev

    Is everyone sitting comfortably?

  17. Kev

    Then let's begin.

  18. Kev

    1) Roll Call.

  19. Kev

    I see a Nathan, a Matt, and Ralph and a Kev.

  20. Kev

    2) Agenda bashing.

  21. MattJ


  22. Kev


  23. MattJ


  24. Fritzy

    Well, is it reasonable to ask that we re-open pubsub collections?

  25. Kev

    We can discuss that at the end, yes.

  26. Fritzy


  27. Fritzy


  28. Kev

    Including a debate about what 're-open' means.

  29. ralphm


  30. Kev

    3) XEP-0060: Publish-Subscribe Version: 1.13rc17 Diff: http://xmpp.org/extensions/diff/api/xep/0060/diff/1.12/vs/1.13rc17 Accept as 1.13?

  31. ralphm

    I had a brief chat with stpeter about this

  32. ralphm

    My proposal about XEP-0060 is the following:

  33. ralphm

    We revert the changes regarding IQ notifications, the removed subids in subscription approvals and the removal of batch publishing.

  34. Kev

    IQ are already gone, aren't they?

  35. ralphm

    The first can be moved to a separate spec if desired by people.

  36. ralphm

    (they are in the online version)

  37. Kev


  38. Kev

    I remember them being gone from the last one we reviewed.

  39. Fritzy

    hm, I didn't see them in rc17

  40. ralphm


  41. stpeter

    hmph, I didn't receive a calendar notification

  42. ralphm

    the removed subids in subscription approval would have issues with content-based subscriptions

  43. ralphm

    so I suggest we revert that change

  44. ralphm

    and regarding removing batch processing: it is not a backwards-compatible change, that I'm unsure about

  45. ralphm

    how it will play out with existing implementations, both client-side and service side

  46. Kev

    We can make non-backwards-compatible changes if we increment the namespace.

  47. ralphm

    so we need to look into that, if we really want to remove it, in a future version

  48. ralphm kicks Kev

  49. stpeter

    I'm fine with reverting those removals pending further discussion -- we can do remove them in 1.14 if necessary (although we did have consensus on removing the batch stuff from last summer)

  50. stpeter

    really I just want to get 1.13 published and then we can have more discussions about the move controversial stuff

  51. ralphm

    I also actually use batch publishing in existing code

  52. ralphm

    what stpeter says

  53. ralphm

    the other changes are mostly cleanups

  54. ralphm

    of which we probably need another batch

  55. Kev

    If it gets 1.13 published, so we can discuss 1.14, I'll go with reverting a couple of changes.

  56. ralphm

    as I discovered through my thorough rereading

  57. ralphm

    also, I think we should not add more stuff to this spec

  58. Kev

    ralphm: so in summary, that's a -1 on this, with suggested changes after which you'll revote positively?

  59. ralphm

    no, I'm +1 with those changes

  60. ralphm

    I don't want to revote

  61. Kev

    Well, yes, I had a dream last night (yes, really), about splitting pubsub down to be trivial, and defining everything in bolt-on specs.

  62. Kev

    Ok, well, I'm +1 with the changed Ralph describes too.

  63. ralphm

    Kev: indeed

  64. Kev

    Fritzy / MattJ?

  65. ralphm

    most of the stuff added could have done in other specs

  66. Fritzy

    I'm +1

  67. ralphm

    and XEP-0060 allows many ways to bolt-on

  68. stpeter

    Kev: yes we've had that discussion too in the past :)

  69. ralphm

    most of it could be discoverable

  70. MattJ

    +1, with ralphm's considerations, I concede he is a pubsub expert more than myself :)

  71. Fritzy

    ralphm: I'd like to address how things get bolted on in 1.15

  72. ralphm

    and config fields can also be added in other specs

  73. Kev

    4) Issue last calls? Candidates are XEPs 234 (Jingle FT), 255 (Location Query), 260 and 261 (Jingle SOCKS5 and IBB).

  74. ralphm

    through the registrar

  75. ralphm

    (e.g. by not using pubsub# prefixes, but another)

  76. Fritzy


  77. Kev

    I think we should either do the f/t block, or location, but not both at once.

  78. Kev

    Which do people think most important?

  79. stpeter

    I posted about the f/t stack on the technical review list earlier today: http://mail.jabber.org/pipermail/techreview/2010-May/000118.html

  80. ralphm


  81. Fritzy

    I think FT.

  82. ralphm

    let's get /that/ done, too, finally

  83. MattJ

    Kev, any reason not to do them together?

  84. Kev

    MattJ: we have a pseudo-policy of only doing 2 last calls togeth.r

  85. stpeter

    how about we give the technical review team two weeks to perform its own review (do location in the meantime) and then have LC on the FT stuff?

  86. Kev

    The f/t stack will be three.

  87. MattJ

    Ok, I wasn't aware of that one :)

  88. MattJ

    stpeter, sounds like a good plan

  89. Kev

    stpeter: I'm happy with that.

  90. Kev

    Fritzy / ralphm?

  91. ralphm

    yeah, that makes sense

  92. stpeter

    and I'll poke the techreview folks about getting busy :)

  93. ralphm

    who's that, right now?

  94. stpeter


  95. Fritzy

    I'm fine with that.

  96. ralphm

    stpeter: ah thanks, I was looking at the XSF pages

  97. Kev

    5) Proto-XEP: Message Carbons http://xmpp.org/extensions/inbox/carbons.html

  98. ralphm

    I'm +1 on publishing

  99. Kev

    This requires server changes, wich is liable to slow adoption, but it seems the right way to be doing this.

  100. Kev


  101. ralphm

    and then have a seat for the battle

  102. stpeter is on the phone now

  103. MattJ

    +1 to publishing

  104. Kev

    I don't think there's a battle, both specs are Joe's.

  105. MattJ

    This is something requested by a lot of people

  106. ralphm

    oh, but Joe isn't the only party ;-)

  107. Kev

    MattJ: right, this does Nice Things.

  108. ralphm

    I just read the standards thread on it

  109. ralphm

    I like the idea

  110. Fritzy

    +1 on this.

  111. Kev

    Ok, so.

  112. Kev

    6) Re-open pubsub collections.

  113. Kev

    What does 're-open' mean?

  114. ralphm

    afaik, it has just been deferred

  115. Fritzy

    I'd just like to do a call for experience.

  116. Fritzy


  117. ralphm

    as I've stated many times before

  118. ralphm

    it needs work

  119. ralphm

    a lot of

  120. Fritzy

    have you implemented it?

  121. ralphm

    partially, yes

  122. Fritzy


  123. Kev

    Fritzy: all it needs is for someone to make an edit for it to be un-deferred.

  124. ralphm

    partially because the spec has all these issues

  125. ralphm

    I can look up my list of concerns

  126. Fritzy

    ralphm: how about you and I discuss what the issues are and I'll put the issues into JIRA or whatever

  127. stpeter

    +1 to Fritzy taking over maintainership if he pleases

  128. Fritzy

    k, cool

  129. Fritzy

    I'm implementing it right now

  130. Fritzy

    and it does need work... but I'd like to see it move, so I can start maintaining it.

  131. ralphm

    Fritzy: sure thing

  132. Kev

    Ok, so nothing to do, Fritzy to start editing.

  133. Kev

    7) Date of next meeting.

  134. Kev

    I've got a week off next week, so I'd ideally like to skip a week, but can arrange to not be away that night if needed.

  135. MattJ

    I'm fine either way

  136. Kev

    Actually, thinking about it, I'm not sure I can make the following week.

  137. Fritzy

    but you can the following week?

  138. Kev

    So do you want to do next week, and if I'm here, I'm here, and if not someone else can chair it.

  139. Kev

    I'll take the silence as a yes.

  140. ralphm

    I like to just schedule every week

  141. Kev


  142. Kev

    Next week then.

  143. Kev

    If I'm not here, someone else can chair.

  144. ralphm


  145. Kev

    8) AOB.

  146. ralphm


  147. Kev

    None from me.

  148. MattJ


  149. Fritzy


  150. ralphm


  151. Kev


  152. Kev

    Thanks all, I'll send out minutes (probably tomorrow).

  153. ralphm

    21 min. Not bad

  154. Kev bangs le gavel.

  155. MattJ


  156. ralphm

    Fritzy: http://mail.jabber.org/pipermail/pubsub/2009-September/000332.html

  157. ralphm

    starts a thread that runs all the way through december

  158. Fritzy

    ralphm: thanks

  159. MattJ

    Kev, now le gavel is banged, at what time did you send the first message "50 minutes"?

  160. Kev

    Ten past 6, BST.

  161. ralphm

    Fritzy: most of my concerns are covered by my lenghty responses

  162. MattJ


  163. Fritzy

    ralphm: cool, I'll pour through it

  164. Kev

    [18:09:13] <Kev> 50 minutes

  165. ralphm

    Fritzy: good luck, let me know if you have any questions

  166. ralphm

    and then pick a slot to hash it all out

  167. Fritzy

    yeah, I'll be in touch on it for sure

  168. ralphm

    I'd prefer to get this over with the two of us, and then present it to the standards list

  169. Fritzy

    sounds good

  170. stpeter notices that the meeting has adjourned :)

  171. mlundblad

    I missed the meeting, are these logged nowadays?

  172. stpeter


  173. stpeter