XMPP Council - 2010-05-03

50 minutes

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

Ok.

That sounds inefficient.

Most

get well

That too.

Thanks :)

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

or the meeting

that's the thing about yesterday

Impressive.

Ok then.

Is everyone sitting comfortably?

Then let's begin.

1) Roll Call.

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

2) Agenda bashing.

Present

Any?

None

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

We can discuss that at the end, yes.

248

ok

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

:-)

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?

I had a brief chat with stpeter about this

My proposal about XEP-0060 is the following:

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

IQ are already gone, aren't they?

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

(they are in the online version)

rc17?

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

hm, I didn't see them in rc17

ok

hmph, I didn't receive a calendar notification

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

so I suggest we revert that change

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

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

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

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

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)

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

I also actually use batch publishing in existing code

what stpeter says

the other changes are mostly cleanups

of which we probably need another batch

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

as I discovered through my thorough rereading

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

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

no, I'm +1 with those changes

I don't want to revote

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

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

Kev: indeed

Fritzy / MattJ?

most of the stuff added could have done in other specs

I'm +1

and XEP-0060 allows many ways to bolt-on

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

most of it could be discoverable

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

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

and config fields can also be added in other specs

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

through the registrar

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

right

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

Which do people think most important?

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

FT

I think FT.

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

Kev, any reason not to do them together?

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

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?

The f/t stack will be three.

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

stpeter, sounds like a good plan

stpeter: I'm happy with that.

Fritzy / ralphm?

yeah, that makes sense

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

who's that, right now?

http://wiki.xmpp.org/web/Review_team

I'm fine with that.

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

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

I'm +1 on publishing

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

+h

and then have a seat for the battle

+1 to publishing

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

This is something requested by a lot of people

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

MattJ: right, this does Nice Things.

I just read the standards thread on it

I like the idea

+1 on this.

Ok, so.

6) Re-open pubsub collections.

What does 're-open' mean?

afaik, it has just been deferred

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

right

as I've stated many times before

it needs work

a lot of

have you implemented it?

partially, yes

DAG?

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

partially because the spec has all these issues

I can look up my list of concerns

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

+1 to Fritzy taking over maintainership if he pleases

k, cool

I'm implementing it right now

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

Fritzy: sure thing

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

7) Date of next meeting.

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.

I'm fine either way

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

but you can the following week?

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

I'll take the silence as a yes.

I like to just schedule every week

Ok.

Next week then.

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

sure

8) AOB.

none

None from me.

None

none

yay!

Excellent.

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

21 min. Not bad

:)

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

starts a thread that runs all the way through december

ralphm: thanks

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

Ten past 6, BST.

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

Thanks

ralphm: cool, I'll pour through it

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

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

and then pick a slot to hash it all out

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

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

sounds good

I missed the meeting, are these logged nowadays?

yes

http://xmpp.org:5290/muc_log/muc.xmpp.org/council/100503/