MattJIf I'm not around when the meeting starts, proceed without me, and I'll vote on-list
KevOk.
MattJhas spent most of the last 48 hours unwell in bed :(
KevThat sounds inefficient.
MattJMost
Fritzyget well
KevThat too.
MattJThanks :)
MattJI'm recovering, had today been yesterday though I wouldn't have remembered the metting at all
MattJor the meeting
Fritzythat's the thing about yesterday
ralphmhas joined
ralphmmaterializes out of thin air
KevImpressive.
KevOk then.
KevIs everyone sitting comfortably?
KevThen let's begin.
Kev1) Roll Call.
KevI see a Nathan, a Matt, and Ralph and a Kev.
Kev2) Agenda bashing.
MattJPresent
KevAny?
MattJNone
FritzyWell, is it reasonable to ask that we re-open pubsub collections?
KevWe can discuss that at the end, yes.
Fritzy248
Fritzyok
KevIncluding a debate about what 're-open' means.
ralphm:-)
Kev3) 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?
ralphmI had a brief chat with stpeter about this
ralphmMy proposal about XEP-0060 is the following:
ralphmWe revert the changes regarding IQ notifications, the removed subids in subscription approvals and the removal of batch publishing.
KevIQ are already gone, aren't they?
ralphmThe first can be moved to a separate spec if desired by people.
ralphm(they are in the online version)
Kevrc17?
KevI remember them being gone from the last one we reviewed.
Fritzyhm, I didn't see them in rc17
stpeterhas joined
ralphmok
stpeterhmph, I didn't receive a calendar notification
ralphmthe removed subids in subscription approval would have issues with content-based subscriptions
ralphmso I suggest we revert that change
ralphmand regarding removing batch processing: it is not a backwards-compatible change, that I'm unsure about
ralphmhow it will play out with existing implementations, both client-side and service side
KevWe can make non-backwards-compatible changes if we increment the namespace.
ralphmso we need to look into that, if we really want to remove it, in a future version
ralphmkicks Kev
stpeterI'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)
stpeterreally I just want to get 1.13 published and then we can have more discussions about the move controversial stuff
ralphmI also actually use batch publishing in existing code
ralphmwhat stpeter says
ralphmthe other changes are mostly cleanups
ralphmof which we probably need another batch
KevIf it gets 1.13 published, so we can discuss 1.14, I'll go with reverting a couple of changes.
ralphmas I discovered through my thorough rereading
ralphmalso, I think we should not add more stuff to this spec
Kevralphm: so in summary, that's a -1 on this, with suggested changes after which you'll revote positively?
ralphmno, I'm +1 with those changes
ralphmI don't want to revote
KevWell, yes, I had a dream last night (yes, really), about splitting pubsub down to be trivial, and defining everything in bolt-on specs.
KevOk, well, I'm +1 with the changed Ralph describes too.
ralphmKev: indeed
KevFritzy / MattJ?
ralphmmost of the stuff added could have done in other specs
FritzyI'm +1
ralphmand XEP-0060 allows many ways to bolt-on
stpeterKev: yes we've had that discussion too in the past :)
ralphmmost of it could be discoverable
MattJ+1, with ralphm's considerations, I concede he is a pubsub expert more than myself :)
Fritzyralphm: I'd like to address how things get bolted on in 1.15
ralphmand config fields can also be added in other specs
Kev4) Issue last calls?
Candidates are XEPs 234 (Jingle FT), 255 (Location Query), 260 and 261
(Jingle SOCKS5 and IBB).
ralphmthrough the registrar
ralphm(e.g. by not using pubsub# prefixes, but another)
Fritzyright
KevI think we should either do the f/t block, or location, but not both at once.
KevWhich do people think most important?
stpeterI posted about the f/t stack on the technical review list earlier today: http://mail.jabber.org/pipermail/techreview/2010-May/000118.html
ralphmFT
FritzyI think FT.
ralphmlet's get /that/ done, too, finally
MattJKev, any reason not to do them together?
KevMattJ: we have a pseudo-policy of only doing 2 last calls togeth.r
stpeterhow 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?
KevThe f/t stack will be three.
MattJOk, I wasn't aware of that one :)
MattJstpeter, sounds like a good plan
Kevstpeter: I'm happy with that.
KevFritzy / ralphm?
ralphmyeah, that makes sense
stpeterand I'll poke the techreview folks about getting busy :)
ralphmwho's that, right now?
stpeterhttp://wiki.xmpp.org/web/Review_team
FritzyI'm fine with that.
ralphmstpeter: ah thanks, I was looking at the XSF pages